10:20 a.m.
On Thu, Dec 24, 2020 at 08:14:29AM -0600, Jonathon Jongsma wrote:
This adds some internal API to query for persistent mediated devices
that are defined by mdevctl. Following commits will make use of this
information. This just provides the infrastructure and tests for this
feature. One test verifies that we are executing mdevctl with the proper
arguments, and the other test verifies that we can parse the returned
JSON and convert it to our own internal node device representations.
Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com>
---
src/node_device/node_device_driver.c | 150 ++++++++++++++++++
src/node_device/node_device_driver.h | 7 +
.../mdevctl-list-defined.argv | 1 +
.../mdevctl-list-multiple.json | 59 +++++++
.../mdevctl-list-multiple.out.xml | 39 +++++
tests/nodedevmdevctltest.c | 95 ++++++++++-
6 files changed, 349 insertions(+), 2 deletions(-)
create mode 100644 tests/nodedevmdevctldata/mdevctl-list-defined.argv
create mode 100644 tests/nodedevmdevctldata/mdevctl-list-multiple.json
create mode 100644 tests/nodedevmdevctldata/mdevctl-list-multiple.out.xml
diff --git a/src/node_device/node_device_driver.c b/src/node_device/node_device_driver.c
index 6143459618..bbd373e32e 100644
--- a/src/node_device/node_device_driver.c
+++ b/src/node_device/node_device_driver.c
@@ -853,6 +853,156 @@ virMdevctlStop(virNodeDeviceDefPtr def)
}
+virCommandPtr
+nodeDeviceGetMdevctlListCommand(bool defined,
+ char **output)
+{
+ virCommandPtr cmd = virCommandNewArgList(MDEVCTL,
+ "list",
+ "--dumpjson",
+ NULL);
+
+ if (defined)
+ virCommandAddArg(cmd, "--defined");
+
+ virCommandSetOutputBuffer(cmd, output);
+
+ return cmd;
+}
+
At this point I think we could split this even further and add the parser code
first and then introduce listing support.
...
+int
+nodeDeviceParseMdevctlJSON(const char *jsonstring,
+ virNodeDeviceDefPtr **devs)
+{
+ int n;
+ g_autoptr(virJSONValue) json_devicelist = NULL;
+ virNodeDeviceDefPtr *outdevs = NULL;
+ size_t noutdevs = 0;
+ size_t i, j;
One declaration per line please (I've seen another one, but not sure if it
was in this patch or some later one).
+
+ json_devicelist = virJSONValueFromString(jsonstring);
+
+ if (!json_devicelist)
+ goto parsefailure;
+
+ if (!virJSONValueIsArray(json_devicelist))
+ goto parsefailure;
+
+ n = virJSONValueArraySize(json_devicelist);
+
+ for (i = 0; i < n; i++) {
+ virJSONValuePtr obj = virJSONValueArrayGet(json_devicelist, i);
+ const char *parent;
+ virJSONValuePtr child_array;
+ int nchildren;
+
+ if (!virJSONValueIsObject(obj))
+ goto parsefailure;
+
+ /* mdevctl returns an array of objects. Each object is a parent device
+ * object containing a single key-value pair which maps from the name
+ * of the parent device to an array of child devices */
+ if (virJSONValueObjectKeysNumber(obj) != 1)
+ goto parsefailure;
+
+ parent = virJSONValueObjectGetKey(obj, 0);
+ child_array = virJSONValueObjectGetValue(obj, 0);
+
+ if (!virJSONValueIsArray(child_array))
+ goto parsefailure;
+
+ nchildren = virJSONValueArraySize(child_array);
+
+ for (j = 0; j < nchildren; j++) {
+ g_autoptr(virNodeDeviceDef) child = NULL;
+ virJSONValuePtr child_obj = virJSONValueArrayGet(child_array, j);
+
+ if (!(child = nodeDeviceParseMdevctlChildDevice(parent, child_obj)))
+ goto parsefailure;
+
+ if (VIR_APPEND_ELEMENT(outdevs, noutdevs, child) < 0)
+ goto parsefailure;
+ }
+ }
+
+ *devs = outdevs;
+ return noutdevs;
+
+ parsefailure:
As pointed out in v2:
s/parsefailure/error
+ for (i = 0; i < noutdevs; i++)
+ virNodeDeviceDefFree(outdevs[i]);
+ VIR_FREE(outdevs);
+
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("unable to parse JSON response"));
+ return -1;
+}
+
+
...
--- /dev/null
+++ b/tests/nodedevmdevctldata/mdevctl-list-multiple.json
@@ -0,0 +1,59 @@
+[
+ {
+ "0000:00:02.0": [
+ {
+ "200f228a-c80a-4d50-bfb7-f5a0e4e34045": {
+ "mdev_type": "i915-GVTg_V5_4",
+ "start": "manual"
+ }
+ },
+ {
+ "de807ffc-1923-4d5f-b6c9-b20ecebc6d4b": {
+ "mdev_type": "i915-GVTg_V5_4",
+ "start": "auto"
+ }
+ },
+ {
+ "435722ea-5f43-468a-874f-da34f1217f13": {
+ "mdev_type": "i915-GVTg_V5_8",
+ "start": "manual",
+ "attrs": [
+ {
+ "testattr": "42"
+ }
+ ]
+ }
+ }
+ ]
+ },
+ {
+ "matrix": [
+ { "783e6dbb-ea0e-411f-94e2-717eaad438bf": {
+ "mdev_type": "vfio_ap-passthrough",
+ "start": "manual",
+ "attrs": [
+ {
+ "assign_adapter": "5"
+ },
+ {
+ "assign_adapter": "6"
+ },
Why are there 2 of each? Does that indicate to mdevctl that when creating an
mdev on the matrix device it can pick any of the adapters for the mdev?
+ {
+ "assign_domain": "0xab"
+ },
+ {
+ "assign_control_domain": "0xab"
+ },
+ {
+ "assign_domain": "4"
+ },
+ {
+ "assign_control_domain": "4"
Are ^these the real life attribute names mdevctl uses for vfio_ap-passthrough?
...
+<device>
+ <name>mdev_435722ea_5f43_468a_874f_da34f1217f13</name>
+ <parent>0000:00:02.0</parent>
+ <capability type='mdev'>
+ <type id='i915-GVTg_V5_8'/>
+ <iommuGroup number='0'/>
+ <attr name='testattr' value='42'/>
+ </capability>
+</device>
+<device>
+ <name>mdev_783e6dbb_ea0e_411f_94e2_717eaad438bf</name>
+ <parent>matrix</parent>
+ <capability type='mdev'>
+ <type id='vfio_ap-passthrough'/>
+ <iommuGroup number='0'/>
+ <attr name='assign_adapter' value='5'/>
+ <attr name='assign_adapter' value='6'/>
+ <attr name='assign_domain' value='0xab'/>
+ <attr name='assign_control_domain' value='0xab'/>
+ <attr name='assign_domain' value='4'/>
+ <attr name='assign_control_domain' value='4'/>
Bjoern was right in his response to v2 when he said this adds quite some noise
for the end user and is not consistent at all with how we represent the AP
scheme. On the other hand, at the time of posting the v2 we already
had introduced and documented the <attr> element, so I still think what you
have here is the right approach because should we have gone with vendor
specific elements the end users might get the impression that libvirt owns the
attributes or IOW is somehow responsible for whether the mdev is going to be
created successfully with these attributes or not - whilst we're just the
middle man and we're merely passing these attributes to mdevctl and we also
document that it's a generic mechanism to allow vendor-specific attributes
to be specified along with the mdev.
However, the end users know nothing about what the names of the attributes are
and what mdevctl accepts, so maybe we could, for XML purposes, name the
attributes the same way as we name the AP elements, i.e. ap-adapter, ap-control
(yeah, it should have been "ap_xyz" I overlooked this during review, so that
is on me). The fact we're using mdevctl underneath is completely transparent
to the end users, so we should strive for at least some kind of consistency
so anyone can tell how the individual node devices relate to each other.
Code-wise I don't see any outstanding problems anymore, so once we come to an
agreement on what the XML needs to look like to make most (ideally all) parties
happy, you have my:
Reviewed-by: Erik Skultety <eskultet(a)redhat.com>