1:38 a.m.
(Thisis "V2 of Part 2". "V1 of Part 2" is here:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5G...
)
Part 1 (which simply made it possible to use virsh nodedev-detach to
bind a device to a manually-specified variant driver, and at guest
runtime allowed libvirt to ignore the fact that the driver found to
the device was something other than exactly "vfio-pci") was here:
https://listman.redhat.com/archives/libvir-list/2023-August/241338.html
and pushed upstream as of commit v9.6.0-153-g24beaffec3
Part 2 adds two new pieces of functionality:
1) It is possible to manually specify a VFIO variant driver (or force
the generic vfio-pci driver) for a device in the domain XML with,
e.g.:
<driver name='mlx5_vfio_pci'/>
(for the former) or:
<driver name='vfio-pci'/>
(for the latter).
2) By default libvirt will now find the "best match" VFIO or VFIO
variant driver by comparing the device's modalias file contents (in
sysfs) with vfio drivers found in the running kernel's
modules.alias file. This means that "virsh nodedev-detach" of a
host device will bind it to its appropriate VFIO variant driver (if
one is available), and also if a <hostdev> decice in a domain
config has "managed='yes'", libvirt will bind it to a variant
driver if possible (in order to force binding to the basic vfio-pci
driver instead, you just need to add the <driver> element mentioned
above).
The first 12 patches are all just getting (1) going (a lot of it is
refactoring code to use common code for the four places that use the
hostdev <driver> element), and the final 3 patches implement (2).
More details are spread along the way.
Differences from V1:
I squashed together a couple of the patches, and fixed some things that caused
CI jobs to fail (I'd forgotten to push the branch to gitlab and
trigger CI).
Laine Stump (15):
util: properly deal with module vs. driver when binding device to
driver
schema: consolidate RNG for all hostdev <driver> elements
conf: move/rename hostdev PCI driver type enum to device_conf.h
conf: normalize hostdev <driver> parsing to simplify adding new attr
conf: put hostdev PCI backend into a struct
conf: use virDeviceHostdevPCIDriverInfo in network and networkport
objects
conf: split out hostdev <driver> parse/format to their own functions
conf: use new common parser/formatter for hostdev driver in network
XML
tests: remove explicit <driver name='vfio'/> from hostdev test cases
xen: explicitly set hostdev driver.type at runtime, not in postparse
conf: replace virHostdevIsVFIODevice with virHostdevIsPCIDevice
conf: support manually specifying VFIO variant driver in <hostdev> XML
util: new function virStringSkipToSpace()
tests: mock virPCIDevice(BindTo|UnbindFrom)Stub with nop functions
qemu: automatically bind to a vfio variant driver, if available
docs/formatdomain.rst | 55 ++-
src/conf/device_conf.c | 75 +++
src/conf/device_conf.h | 27 ++
src/conf/domain_capabilities.c | 2 +-
src/conf/domain_capabilities.h | 2 +-
src/conf/domain_conf.c | 98 +---
src/conf/domain_conf.h | 18 +-
src/conf/network_conf.c | 43 +-
src/conf/network_conf.h | 17 +-
src/conf/schemas/basictypes.rng | 20 +
src/conf/schemas/domaincommon.rng | 173 ++++---
src/conf/schemas/network.rng | 10 +-
src/conf/schemas/networkport.rng | 10 +-
src/conf/virconftypes.h | 2 +
src/conf/virnetworkportdef.c | 22 +-
src/conf/virnetworkportdef.h | 4 +-
src/hypervisor/virhostdev.c | 16 +-
src/hypervisor/virhostdev.h | 2 -
src/libvirt_private.syms | 10 +-
src/libxl/libxl_capabilities.c | 2 +-
src/libxl/libxl_domain.c | 65 ++-
src/libxl/libxl_driver.c | 25 +-
src/network/bridge_driver.c | 2 +-
src/qemu/qemu_capabilities.c | 4 +-
src/qemu/qemu_command.c | 14 +-
src/qemu/qemu_domain.c | 29 +-
src/qemu/qemu_hostdev.c | 2 +-
src/qemu/qemu_hotplug.c | 2 +-
src/qemu/qemu_validate.c | 6 +-
src/security/security_apparmor.c | 2 +-
src/security/security_dac.c | 4 +-
src/security/security_selinux.c | 4 +-
src/security/virt-aa-helper.c | 8 +-
src/util/virpci.c | 438 ++++++++++++++++--
src/util/virpci.h | 3 +
src/util/virstring.c | 17 +
src/util/virstring.h | 1 +
tests/domaincapstest.c | 4 +-
tests/libxlxml2domconfigdata/moredevs-hvm.xml | 1 -
tests/networkxml2xmlin/hostdev-pf-old.xml | 8 +
tests/networkxml2xmlin/hostdev-pf.xml | 2 +-
tests/networkxml2xmlout/hostdev-pf-old.xml | 8 +
tests/networkxml2xmlout/hostdev-pf.xml | 2 +-
tests/networkxml2xmltest.c | 6 +
tests/qemuhotplugmock.c | 15 +
.../qemuhotplug-hostdev-pci.xml | 1 -
.../qemuhotplug-base-live+hostdev-pci.xml | 2 +-
...uhotplug-pseries-base-live+hostdev-pci.xml | 2 +-
tests/qemustatusxml2xmldata/modern-in.xml | 2 +-
.../hostdev-pci-address-unassigned.xml | 4 -
.../hostdev-pci-multifunction.xml | 7 -
.../hostdev-vfio-multidomain.xml | 1 -
.../hostdev-vfio-zpci-autogenerate-fids.xml | 2 -
.../hostdev-vfio-zpci-autogenerate-uids.xml | 2 -
.../hostdev-vfio-zpci-autogenerate.xml | 1 -
.../hostdev-vfio-zpci-boundaries.xml | 2 -
.../hostdev-vfio-zpci-ccw-memballoon.xml | 1 -
.../hostdev-vfio-zpci-duplicate.xml | 2 -
...ostdev-vfio-zpci-invalid-uid-valid-fid.xml | 1 -
.../hostdev-vfio-zpci-multidomain-many.xml | 8 -
.../hostdev-vfio-zpci-set-zero.xml | 1 -
.../hostdev-vfio-zpci-uid-set-zero.xml | 1 -
.../hostdev-vfio-zpci-wrong-arch.xml | 1 -
tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 1 -
.../hostdev-vfio.x86_64-latest.args | 5 +-
tests/qemuxml2argvdata/hostdev-vfio.xml | 19 +-
.../net-hostdev-vfio-multidomain.xml | 1 -
tests/qemuxml2argvdata/net-hostdev-vfio.xml | 1 -
tests/qemuxml2argvdata/pseries-hostdevs-1.xml | 3 -
tests/qemuxml2argvdata/pseries-hostdevs-2.xml | 2 -
tests/qemuxml2argvdata/pseries-hostdevs-3.xml | 2 -
...v-pci-address-unassigned.x86_64-latest.xml | 4 -
...ostdev-pci-multifunction.x86_64-latest.xml | 7 -
...io-zpci-autogenerate-fids.s390x-latest.xml | 2 -
...io-zpci-autogenerate-uids.s390x-latest.xml | 2 -
...ev-vfio-zpci-autogenerate.s390x-latest.xml | 1 -
...tdev-vfio-zpci-boundaries.s390x-latest.xml | 2 -
...-vfio-zpci-ccw-memballoon.s390x-latest.xml | 1 -
...fio-zpci-multidomain-many.s390x-latest.xml | 8 -
.../hostdev-vfio-zpci.s390x-latest.xml | 1 -
.../hostdev-vfio.x86_64-latest.xml | 24 +-
.../net-hostdev-vfio.x86_64-latest.xml | 1 -
.../pseries-hostdevs-1.ppc64-latest.xml | 3 -
.../pseries-hostdevs-2.ppc64-latest.xml | 2 -
.../pseries-hostdevs-3.ppc64-latest.xml | 2 -
tests/virhostdevtest.c | 2 +-
.../plug-hostdev-pci-unmanaged.xml | 2 +-
.../plug-hostdev-pci.xml | 2 +-
tests/xlconfigdata/test-fullvirt-pci.xml | 2 -
tests/xmconfigdata/test-pci-dev-syntax.xml | 2 -
tests/xmconfigdata/test-pci-devs.xml | 2 -
tools/virsh-completer-nodedev.c | 4 +-
92 files changed, 933 insertions(+), 498 deletions(-)
create mode 100644 tests/networkxml2xmlin/hostdev-pf-old.xml
create mode 100644 tests/networkxml2xmlout/hostdev-pf-old.xml
--
2.41.0
1:38 a.m.
New subject: [libvirt PATCH v2 01/15] util: properly deal with module vs. driver when binding device to driver
Historically libvirt has treated the concept of "loadable kernel
module" and "device driver" as being effectively the same (at least in
the case of the vfio-pci driver used for VFIO device assignment). The
code assumed that a module named "vfio-pci" implemented a driver named
"vfio-pci".
In reality, the module is named "vfio_pci", and it implements a device
driver named "vfio-pci" (note the difference in separator characters),
and our code worked only because the modprobe utility we use to load
the module will always "normalize" the module name it's given by
replacing all "-" (dash) with "_" (underscore) (this has been
verified
in the modprobe source, which is in the kmod package - there are 3
separate functions that perform this same operation!). So even though
we asked modprobe to load the "vfio-pci" module, it would actually
load the "vfio_pci" module.
After loading the module with modprobe, libvirt then looks for the
desired *driver* to be present in sysfs, by looking for the directory
/sys/bus/pci/drivers/${driverName}, which would succeed because we
were still looking for the original "dash version" of the name
("vfio-pci").
When we recently gained the ability to manually specify a driver to
bind to with virsh nodedev-detach, the fragility of this system became
apparent - if a user gives the driver name as "vfio_pci", then we
would modprobe the module, but then erroneously believe it hadn't been
loaded because /sys/bus/pci/drivers/vfio_pci didn't exist. For manual
specification of the driver name, this could be dealt with by telling
the user "always use the correct name for the driver, don't assume
that it is the same as the modulename", but it would still end up
confusing people, especially since some drivers do use underscore in
their name (e.g. the mlx5_vfio_pci driver/module).
More more importantly, when we begin looking in the modules.alias file
for the "best" VFIO variant driver for a particular device (in an
upcoming patch), that lookup will provide us with the name of a
*module*, not a driver, and 3 of the 4 examples of vfio-pci/variant
drivers I have access to use underscore in the module name and dash in
the driver, while the 4th uses underscore in both, so 3 out of 4 fail
with the current code.
To make the current code more forgiving (and yet more correct!), as
well as to make the upcoming variant auto-selection actually useful,
this patch follows the following steps:
1) if the requested driver (${driverName}) is present in sysfs drivers
list (/sys/bus/pci/drivers/${driverName}) then use ${driverName} -
DONE
2) if underscored(${driverName}) (call it ${underName} for short) is
in sysfs drivers list then use ${underName} - DONE
3) if ${underName} *isn't* in the sysfs modules list
(/sys/module/${underName}) then "modprobe ${underName}" to load it.
4) look for the PCI driver implemented by this module, it will
be at /sys/module/${underName}/driver/pci:${newName}.
5) use ${newName} - DONE.
A few notes:
a) This will *always* replace dash with underscore in the name used to
load the module, which seems it could be problematic, but I have
verified this is what modprobe itself does, so I don't think there
will ever be a module with "-" in its name as modprobe would be
unable to load it (the same can't be said for drivers though!)
b) The one case where the above steps wouldn't work would be if
someone implemented a driver within a module where the driver and
module had names that differed other than dash vs. underscore. I
haven't seen an example of this, so the convention seems to be that
they will "match" (modulo - & _). If this mismatch were to ever
occur, though, it could be worked around by simply loading the
module out-of-band during the host system startup, and then using
the driver's name in the config.
c) All of this is conveniently ignoring the possibility of a VFIO
variant driver that is statically linked in the kernel. The entire
design of variant driver auto-detection is based on doing a lookup
in modules.alias, and that only lists *loadable modules* (not
drivers), so unless I'm missing something, it would be impossible
to auto-detect a VFIO variant driver that was statically
linked. This is beyond libvirt's ability to fix; the best that
could be done would be to manually specify the driver name in the
libvirt config, which I suppose is better than nothing :-)
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/util/virpci.c | 194 +++++++++++++++++++++++++++++++++++++++-------
1 file changed, 164 insertions(+), 30 deletions(-)
diff --git a/src/util/virpci.c b/src/util/virpci.c
index baacde4c14..dfc97dc981 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -221,6 +221,13 @@ virPCIDriverDir(const char *driver)
}
+static char *
+virPCIModuleDir(const char *module)
+{
+ return g_strdup_printf("/sys/module/%s", module);
+}
+
+
static char *
virPCIFile(const char *device, const char *file)
{
@@ -1153,44 +1160,167 @@ virPCIDeviceReset(virPCIDevice *dev,
}
+/**
+ * virPCINameDashToUnderscore:
+ * @path: the module/driver name or path - will be directly modified
+ *
+ * Replace all occurences of "-" with "_" in the name
+ * part of the path (everything after final "/"
+ *
+ * return true if any change was made, otherwise false.
+ */
static int
-virPCIProbeDriver(const char *driverName)
+virPCINameDashToUnderscore(char *path)
{
- g_autofree char *drvpath = NULL;
+ bool changed = false;
+ char *tmp = strrchr(path, '/');
+
+ if (!tmp)
+ tmp = path;
+
+ while (*tmp) {
+ if (*tmp == '-') {
+ *tmp = '_';
+ changed = true;
+ }
+ tmp++;
+ }
+
+ return changed;
+}
+
+
+static int
+virPCIProbeModule(const char *moduleName)
+{
+ g_autofree char *modulePath = NULL;
g_autofree char *errbuf = NULL;
- drvpath = virPCIDriverDir(driverName);
+ modulePath = virPCIModuleDir(moduleName);
/* driver previously loaded, return */
- if (virFileExists(drvpath))
+ if (virFileExists(modulePath))
return 0;
- if ((errbuf = virKModLoad(driverName))) {
- VIR_WARN("failed to load driver %s: %s", driverName, errbuf);
- goto cleanup;
+ if ((errbuf = virKModLoad(moduleName))) {
+ /* If we know failure was because of admin config, let's report that;
+ * otherwise, report a more generic failure message
+ */
+ if (virKModIsProhibited(moduleName)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Failed to load PCI driver module %1$s:
administratively prohibited"),
+ moduleName);
+ } else {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Failed to load PCI driver module %1$s: %2$s"),
+ moduleName, errbuf);
+ }
+ return -1;
}
/* driver loaded after probing */
- if (virFileExists(drvpath))
+ if (virFileExists(modulePath))
return 0;
- cleanup:
- /* If we know failure was because of admin config, let's report that;
- * otherwise, report a more generic failure message
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("modprobe reported success loading module '%1$s', but
module is missing from /sys/module"),
+ moduleName);
+ return -1;
+}
+
+/**
+ * virPCIDeviceFindDriver:
+ * @dev: initialized virPCIDevice, including desired stubDriverName
+ *
+ * Checks if there is a driver named @dev->stubDriverName already
+ * loaded. If there is, we're done. If not, look for a driver with
+ * that same name, except with dashes replaced with underscores.
+
+ * If neither of the above is found, then look for/load the module of
+ * the underscored version of the name, and follow the links from
+ * /sys/module/$name/drivers/pci:* to the PCI driver associated with that
+ * module, and update @dev->stubDriverName with that name.
+ *
+ * On a successful return, @dev->stubDriverName will be updated with
+ * the proper name for the driver, and that driver will be loaded.
+ *
+ * returns 0 on success, -1 on failure
+ */
+static int
+virPCIDeviceFindDriver(virPCIDevice *dev)
+{
+ g_autofree char *driverPath = virPCIDriverDir(dev->stubDriverName);
+ g_autofree char *moduleName = NULL;
+ g_autofree char *moduleDriversDir = NULL;
+ g_autoptr(DIR) dir = NULL;
+ struct dirent *ent;
+ int direrr;
+
+ /* unchanged stubDriverName */
+ if (virFileExists(driverPath))
+ return 0;
+
+ /* try replacing "-" with "_" */
+ if (virPCINameDashToUnderscore(driverPath)
+ && virFileExists(driverPath)) {
+
+ /* update original name in dev */
+ virPCINameDashToUnderscore(dev->stubDriverName);
+ return 0;
+ }
+
+ /* look for a module with this name (but always replacing
+ * "-" with "_", since that's what modprobe does)
*/
- if (virKModIsProhibited(driverName)) {
- virReportError(VIR_ERR_INTERNAL_ERROR,
- _("Failed to load PCI driver module %1$s: administratively
prohibited"),
- driverName);
- } else {
- virReportError(VIR_ERR_INTERNAL_ERROR,
- _("Failed to load PCI driver module %1$s"),
- driverName);
+
+ moduleName = g_strdup(dev->stubDriverName);
+ virPCINameDashToUnderscore(moduleName);
+
+ if (virPCIProbeModule(moduleName) < 0)
+ return -1;
+
+ /* module was found/loaded. Now find the PCI driver it implements,
+ * linked to by /sys/module/$moduleName/drivers/pci:$driverName
+ */
+
+ moduleDriversDir = g_strdup_printf("/sys/module/%s/drivers", moduleName);
+
+ if (virDirOpen(&dir, moduleDriversDir) < 0)
+ return -1;
+
+ while ((direrr = virDirRead(dir, &ent, moduleDriversDir))) {
+
+ if (STRPREFIX(ent->d_name, "pci:")) {
+ /* this is the link to the driver we want */
+
+ g_autofree char *drvName = NULL;
+ g_autofree char *drvPath = NULL;
+
+ /* extract the driver name from the link name */
+ drvName = g_strdup(ent->d_name + strlen("pci:"));
+
+ /* make sure that driver is actually loaded */
+ drvPath = virPCIDriverDir(drvName);
+ if (!virFileExists(drvPath)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("pci driver '%1$s' supposedly loaded by
module '%2$s' not found in sysfs"),
+ drvName, moduleName);
+ return -1;
+ }
+
+ g_free(dev->stubDriverName);
+ dev->stubDriverName = g_steal_pointer(&drvName);
+ return 0;
+ }
}
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("module '%1$s' does not implement any pci
driver"),
+ moduleName);
return -1;
}
+
int
virPCIDeviceUnbind(virPCIDevice *dev)
{
@@ -1290,7 +1420,6 @@ virPCIDeviceUnbindFromStub(virPCIDevice *dev)
static int
virPCIDeviceBindToStub(virPCIDevice *dev)
{
- const char *stubDriverName = dev->stubDriverName;
g_autofree char *stubDriverPath = NULL;
g_autofree char *driverLink = NULL;
@@ -1302,30 +1431,35 @@ virPCIDeviceBindToStub(virPCIDevice *dev)
return -1;
}
- if (!stubDriverName
- && !(stubDriverName =
virPCIStubDriverTypeToString(dev->stubDriverType))) {
- virReportError(VIR_ERR_INTERNAL_ERROR,
- _("Unknown stub driver configured for PCI device
%1$s"),
- dev->name);
- return -1;
+ if (!dev->stubDriverName) {
+
+ const char *stubDriverName = NULL;
+
+ if (!(stubDriverName = virPCIStubDriverTypeToString(dev->stubDriverType))) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Unknown stub driver configured for PCI device
%1$s"),
+ dev->name);
+ return -1;
+ }
+ dev->stubDriverName = g_strdup(stubDriverName);
}
- if (virPCIProbeDriver(stubDriverName) < 0)
+ if (virPCIDeviceFindDriver(dev) < 0)
return -1;
- stubDriverPath = virPCIDriverDir(stubDriverName);
+ stubDriverPath = virPCIDriverDir(dev->stubDriverName);
driverLink = virPCIFile(dev->name, "driver");
if (virFileExists(driverLink)) {
if (virFileLinkPointsTo(driverLink, stubDriverPath)) {
/* The device is already bound to the correct driver */
VIR_DEBUG("Device %s is already bound to %s",
- dev->name, stubDriverName);
+ dev->name, dev->stubDriverName);
return 0;
}
}
- if (virPCIDeviceBindWithDriverOverride(dev, stubDriverName) < 0)
+ if (virPCIDeviceBindWithDriverOverride(dev, dev->stubDriverName) < 0)
return -1;
dev->unbind_from_stub = true;
--
2.41.0
7:21 a.m.
New subject: [libvirt PATCH v2 01/15] util: properly deal with module vs.
driver when binding device to driver
The commit message is longer than it needs to be and the long
explanation actually made it harder to comprehend for me.
On a Monday in 2023, Laine Stump wrote:
Historically libvirt has treated the concept of "loadable kernel
module" and "device driver" as being effectively the same (at least in
the case of the vfio-pci driver used for VFIO device assignment). The
code assumed that a module named "vfio-pci" implemented a driver named
"vfio-pci".
In reality, the module is named "vfio_pci", and it implements a device
driver named "vfio-pci" (note the difference in separator characters),
The note about the difference in characters is not needed if you mention
them explicitly below.
and our code worked only because the modprobe utility we use to load
the module will always "normalize" the module name it's given by
replacing all "-" (dash) with "_" (underscore) (this has been
verified
in the modprobe source, which is in the kmod package - there are 3
separate functions that perform this same operation!).
My package manager can tell me which package modprobe is in and I don't
need to know the number of functions.
So even though
we asked modprobe to load the "vfio-pci" module, it would actually
load the "vfio_pci" module.
After loading the module with modprobe, libvirt then looks for the
desired *driver* to be present in sysfs, by looking for the directory
/sys/bus/pci/drivers/${driverName}, which would succeed because we
were still looking for the original "dash version" of the name
("vfio-pci").
When we recently gained the ability to manually specify a driver to
bind to with virsh nodedev-detach, the fragility of this system became
apparent - if a user gives the driver name as "vfio_pci", then we
would modprobe the module, but then erroneously believe it hadn't been
loaded because /sys/bus/pci/drivers/vfio_pci didn't exist. For manual
specification of the driver name, this could be dealt with by telling
the user "always use the correct name for the driver, don't assume
that it is the same as the modulename", but it would still end up
confusing people, especially since some drivers do use underscore in
their name (e.g. the mlx5_vfio_pci driver/module).
More more importantly, when we begin looking in the modules.alias file
for the "best" VFIO variant driver for a particular device (in an
upcoming patch), that lookup will provide us with the name of a
*module*, not a driver, and 3 of the 4 examples of vfio-pci/variant
drivers I have access to use underscore in the module name and dash in
the driver, while the 4th uses underscore in both, so 3 out of 4 fail
with the current code.
To make the current code more forgiving (and yet more correct!), as
well as to make the upcoming variant auto-selection actually useful,
this patch follows the following steps:
1) if the requested driver (${driverName}) is present in sysfs drivers
list (/sys/bus/pci/drivers/${driverName}) then use ${driverName} -
DONE
I did not see any response to Jason's points in v1:
https://listman.redhat.com/archives/libvir-list/2023-October/242780.html
I think we can safely assume that modprobe will accept a dashed name
and that module names are using underscores.
Is the problem here that you cannot figure out the driver the module
provides until after it's loaded?
Jano
2) if underscored(${driverName}) (call it ${underName} for short) is
in sysfs drivers list then use ${underName} - DONE
3) if ${underName} *isn't* in the sysfs modules list
(/sys/module/${underName}) then "modprobe ${underName}" to load it.
4) look for the PCI driver implemented by this module, it will
be at /sys/module/${underName}/driver/pci:${newName}.
5) use ${newName} - DONE.
A few notes:
a) This will *always* replace dash with underscore in the name used to
load the module, which seems it could be problematic, but I have
verified this is what modprobe itself does, so I don't think there
will ever be a module with "-" in its name as modprobe would be
unable to load it (the same can't be said for drivers though!)
b) The one case where the above steps wouldn't work would be if
someone implemented a driver within a module where the driver and
module had names that differed other than dash vs. underscore. I
haven't seen an example of this, so the convention seems to be that
they will "match" (modulo - & _). If this mismatch were to ever
occur, though, it could be worked around by simply loading the
module out-of-band during the host system startup, and then using
the driver's name in the config.
c) All of this is conveniently ignoring the possibility of a VFIO
variant driver that is statically linked in the kernel. The entire
design of variant driver auto-detection is based on doing a lookup
in modules.alias, and that only lists *loadable modules* (not
drivers), so unless I'm missing something, it would be impossible
to auto-detect a VFIO variant driver that was statically
linked. This is beyond libvirt's ability to fix; the best that
could be done would be to manually specify the driver name in the
libvirt config, which I suppose is better than nothing :-)
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/util/virpci.c | 194 +++++++++++++++++++++++++++++++++++++++-------
1 file changed, 164 insertions(+), 30 deletions(-)
12:28 p.m.
New subject: [libvirt PATCH v2 01/15] util: properly deal with module vs.
driver when binding device to driver
On 11/28/23 8:21 AM, Ján Tomko wrote:
The commit message is longer than it needs to be and the long
explanation actually made it harder to comprehend for me.
Well, without *enough* explanation, it all seems like pointlessly
pushing bits around :-). I guess my extra explanation failed though,
since people have had issues with the patch twice now).
On a Monday in 2023, Laine Stump wrote:
> Historically libvirt has treated the concept of "loadable kernel
> module" and "device driver" as being effectively the same (at least
in
> the case of the vfio-pci driver used for VFIO device assignment). The
> code assumed that a module named "vfio-pci" implemented a driver named
> "vfio-pci".
>
> In reality, the module is named "vfio_pci", and it implements a device
> driver named "vfio-pci" (note the difference in separator characters),
The note about the difference in characters is not needed if you mention
them explicitly below.
I suppose I can remove it. Reading the paragraph by itself, though, it
sounds like 'His name is "Bob", not "*Bob*"'.
> and our code worked only because the modprobe utility we use to load
> the module will always "normalize" the module name it's given by
> replacing all "-" (dash) with "_" (underscore) (this has been
verified
> in the modprobe source, which is in the kmod package - there are 3
> separate functions that perform this same operation!).
My package manager can tell me which package modprobe is in and I don't
need to know the number of functions.
My spidey senses tell me someone is getting fed up with my verbose
explanations :-). I'll try to be more brief.
> So even though
> we asked modprobe to load the "vfio-pci" module, it would actually
> load the "vfio_pci" module.
>
> After loading the module with modprobe, libvirt then looks for the
> desired *driver* to be present in sysfs, by looking for the directory
> /sys/bus/pci/drivers/${driverName}, which would succeed because we
> were still looking for the original "dash version" of the name
> ("vfio-pci").
>
> When we recently gained the ability to manually specify a driver to
> bind to with virsh nodedev-detach, the fragility of this system became
> apparent - if a user gives the driver name as "vfio_pci", then we
> would modprobe the module, but then erroneously believe it hadn't been
> loaded because /sys/bus/pci/drivers/vfio_pci didn't exist. For manual
> specification of the driver name, this could be dealt with by telling
> the user "always use the correct name for the driver, don't assume
> that it is the same as the modulename", but it would still end up
> confusing people, especially since some drivers do use underscore in
> their name (e.g. the mlx5_vfio_pci driver/module).
>
> More more importantly, when we begin looking in the modules.alias file
> for the "best" VFIO variant driver for a particular device (in an
> upcoming patch), that lookup will provide us with the name of a
> *module*, not a driver, and 3 of the 4 examples of vfio-pci/variant
> drivers I have access to use underscore in the module name and dash in
> the driver, while the 4th uses underscore in both, so 3 out of 4 fail
> with the current code.
>
> To make the current code more forgiving (and yet more correct!), as
> well as to make the upcoming variant auto-selection actually useful,
> this patch follows the following steps:
>
> 1) if the requested driver (${driverName}) is present in sysfs drivers
> list (/sys/bus/pci/drivers/${driverName}) then use ${driverName} -
> DONE
>
I did not see any response to Jason's points in v1:
https://listman.redhat.com/archives/libvir-list/2023-October/242780.html
I did send a response, but I sent it after the list switched to the new
server, so you won't find it in the old archives (actually when I
originally replied I forgot to change the list address, and then had to
resend):
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/W...
I think we can safely assume that modprobe will accept a dashed name
and that module names are using underscores.
Yes. But you can't assume that the driver name will use dashes, nor even
that the driver name will resemble the module name in any
programmatically derivable way - although it is common convention that
the module name be underscored(drivername), driver name is *not*
dashed(modulename).
(Technically it is even possible (although I've not seen it) that the
driver and module names might be completely unrelated - e.g. module
"foo" implementing driver "bar". Sure, we could assume that will never
happen, but then in 5 years someone will do that and libvirt 15.2.0 will
break because of this assumption made 5 years prior, and some poor soul
will have to spend a bunch of time figuring out why.)
Is the problem here that you cannot figure out the driver the module
provides until after it's loaded?
Yes, that is true. But also:
1) users may know the driver name or the module name, and usually don't
know the difference between the two, or even that there are two
different names. This blurring between the two has been exacerbated by
modprobe always converting "-" into "_", so someone using
"vfio-pci"
will still automatically get the proper module loaded (because the
module just happens to be "vfio_pci"), and binding the new driver will
also work properly, but if they use the module name (vfio_pci), then the
module will be loaded, but the driver bind will fail. We could just log
an error, but
"driver 'vfio_pci' not found"
is pretty uninformative, and
"driver 'vfio_pci' not found - maybe try 'vfio-pci'
instead"
is kind of pointless - if we already know how to fix the problem, why
not just fix it and continue on? (you can bet that if we don't, there
will be bug reports saying "Why don't you just automatically fix this
instead of just telling me exactly how to fix it?!?!?". As a matter of
fact, I'd already had bugs filed because "vfio_pci" wasn't accepted
"even though mlx5_vfio_pci is", which is at least part of the origin
story of this patch)
2) modules.alias deals only with *module* names, while each device's
driver_override file in sysfs only understands *driver* names. And even
if we insist that the user specify the driver name, libvirt's own code
(see patch 14/15) will be retrieving the *module* name from the
modules.alias file, and there will need to be code in libvirt to convert
that to driver name in order for the bind operation to be successful.
I'm just fixing that in this patch in order to simplify the later patch,
and also make user-specified <driver name="blah"/> more foolproof.
In the end, all I'm doing is:
1) Making it more clear in libvirt's code where we are using a module
name and where we are using a driver name.
1.5) explicitly performing the "dash to underscore" transformation to
derive a modulename from the user-provided "driver-module name", but
only because we need to follow links in sysfs, and those links *don't*
benefit from modprobe's automatic replacement of dash with underscore
(i.e. even though we can assume that modprobe will always replace dash
with underscore, modprobe isn't the only place that we need the
underscore version of the name)
2) following links in sysfs to derive a driver name from a module name,
rather than making the *incorrect* assumption that we can get that with
dashed(modulename) (which already doesn't work, e.g. for
mlx5_vfio_pci/mlx5_vfio_pci) (with current functionality this just
automatically fixes a common user error, but beginning with patch 14/15
it will actually be essential to proper functioning of variant driver
auto-detect)
There is really nothing controversial going on here. Maybe I just spent
so much time explaining that everyone *thinks* there must be something
fishy.
Jano
> 2) if underscored(${driverName}) (call it ${underName} for short) is
> in sysfs drivers list then use ${underName} - DONE
>
> 3) if ${underName} *isn't* in the sysfs modules list
> (/sys/module/${underName}) then "modprobe ${underName}" to load it.
>
> 4) look for the PCI driver implemented by this module, it will
> be at /sys/module/${underName}/driver/pci:${newName}.
>
> 5) use ${newName} - DONE.
>
> A few notes:
>
> a) This will *always* replace dash with underscore in the name used to
> load the module, which seems it could be problematic, but I have
> verified this is what modprobe itself does, so I don't think there
> will ever be a module with "-" in its name as modprobe would be
> unable to load it (the same can't be said for drivers though!)
>
> b) The one case where the above steps wouldn't work would be if
> someone implemented a driver within a module where the driver and
> module had names that differed other than dash vs. underscore. I
> haven't seen an example of this, so the convention seems to be that
> they will "match" (modulo - & _). If this mismatch were to ever
> occur, though, it could be worked around by simply loading the
> module out-of-band during the host system startup, and then using
> the driver's name in the config.
>
> c) All of this is conveniently ignoring the possibility of a VFIO
> variant driver that is statically linked in the kernel. The entire
> design of variant driver auto-detection is based on doing a lookup
> in modules.alias, and that only lists *loadable modules* (not
> drivers), so unless I'm missing something, it would be impossible
> to auto-detect a VFIO variant driver that was statically
> linked. This is beyond libvirt's ability to fix; the best that
> could be done would be to manually specify the driver name in the
> libvirt config, which I suppose is better than nothing :-)
>
> Signed-off-by: Laine Stump <laine(a)redhat.com>
> ---
> src/util/virpci.c | 194 +++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 164 insertions(+), 30 deletions(-)
>
_______________________________________________
Devel mailing list -- devel(a)lists.libvirt.org
To unsubscribe send an email to devel-leave(a)lists.libvirt.org
1:38 a.m.
New subject: [libvirt PATCH v2 02/15] schema: consolidate RNG for all hostdev <driver> elements
The exact same element can appear in <hostdev> and <interface
type='hostdev'>, and nearly identical in <network> and
<networkport>
(these latter two don't include "xen" as a possible driver, but that's
coincidental - there's no reason Xen couldn't also use the VF pools in
virtual networks, it just doesn't).
This patch modifies all 4 to use the same <ref name="hostdevDriver"/>
so that it is simpler to add something new.
A side effect of this patch is that the grammar for the <interface>
element in domain XML has been tightened up a bit - previously it was
accepted by the schema (but nonsensical) to have virtio and network
interface options specified; as a part of making the two different
<driver> choices each a complete element (rather than each being a
collection of attributes and subelements) these extra
attributes/subelements that were irrelevant to the hostdev-type
<driver> were made to be valid only for an emulated interface's
<driver>.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/schemas/basictypes.rng | 13 +++
src/conf/schemas/domaincommon.rng | 173 ++++++++++++++----------------
src/conf/schemas/network.rng | 10 +-
src/conf/schemas/networkport.rng | 10 +-
4 files changed, 94 insertions(+), 112 deletions(-)
diff --git a/src/conf/schemas/basictypes.rng b/src/conf/schemas/basictypes.rng
index 26eb538077..8d5f4475ca 100644
--- a/src/conf/schemas/basictypes.rng
+++ b/src/conf/schemas/basictypes.rng
@@ -656,4 +656,17 @@
</choice>
</define>
+ <define name="hostdevDriver">
+ <element name="driver">
+ <attribute name="name">
+ <choice>
+ <value>kvm</value>
+ <value>vfio</value>
+ <value>xen</value>
+ </choice>
+ </attribute>
+ <empty/>
+ </element>
+ </define>
+
</grammar>
diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng
index a26986b5ce..002587db58 100644
--- a/src/conf/schemas/domaincommon.rng
+++ b/src/conf/schemas/domaincommon.rng
@@ -3759,18 +3759,12 @@
</element>
</optional>
<optional>
- <element name="driver">
- <choice>
- <group>
- <attribute name="name">
- <choice>
- <value>kvm</value>
- <value>vfio</value>
- <value>xen</value>
- </choice>
- </attribute>
- </group>
- <group>
+ <choice>
+ <group>
+ <ref name="hostdevDriver"/>
+ </group>
+ <group>
+ <element name="driver">
<optional>
<attribute name="name">
<choice>
@@ -3808,90 +3802,90 @@
<optional>
<ref name="event_idx"/>
</optional>
- </group>
- </choice>
- <ref name="virtioOptions"/>
- <interleave>
- <optional>
- <element name="host">
- <optional>
- <attribute name="csum">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
- <optional>
- <attribute name="gso">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
- <optional>
- <attribute name="tso4">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
- <optional>
- <attribute name="tso6">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
- <optional>
- <attribute name="ecn">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
- <optional>
- <attribute name="ufo">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
- <optional>
- <attribute name="mrg_rxbuf">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
- </element>
- </optional>
- <optional>
- <element name="guest">
- <optional>
- <attribute name="csum">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
+ <ref name="virtioOptions"/>
+ <interleave>
<optional>
- <attribute name="tso4">
- <ref name="virOnOff"/>
- </attribute>
+ <element name="host">
+ <optional>
+ <attribute name="csum">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="gso">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="tso4">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="tso6">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="ecn">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="ufo">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="mrg_rxbuf">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ </element>
</optional>
<optional>
- <attribute name="tso6">
- <ref name="virOnOff"/>
- </attribute>
+ <element name="guest">
+ <optional>
+ <attribute name="csum">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="tso4">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="tso6">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="ecn">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="ufo">
+ <ref name="virOnOff"/>
+ </attribute>
+ </optional>
+ </element>
</optional>
<optional>
- <attribute name="ecn">
+ <attribute name="rss">
<ref name="virOnOff"/>
</attribute>
</optional>
<optional>
- <attribute name="ufo">
+ <attribute name="rss_hash_report">
<ref name="virOnOff"/>
</attribute>
</optional>
- </element>
- </optional>
- <optional>
- <attribute name="rss">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
- <optional>
- <attribute name="rss_hash_report">
- <ref name="virOnOff"/>
- </attribute>
- </optional>
- </interleave>
- </element>
+ </interleave>
+ </element>
+ </group>
+ </choice>
</optional>
<optional>
<ref name="alias"/>
@@ -6182,16 +6176,7 @@
</attribute>
<interleave>
<optional>
- <element name="driver">
- <attribute name="name">
- <choice>
- <value>kvm</value>
- <value>vfio</value>
- <value>xen</value>
- </choice>
- </attribute>
- <empty/>
- </element>
+ <ref name="hostdevDriver"/>
</optional>
<optional>
<ref name="teaming"/>
diff --git a/src/conf/schemas/network.rng b/src/conf/schemas/network.rng
index cda174ab4b..e56e07d130 100644
--- a/src/conf/schemas/network.rng
+++ b/src/conf/schemas/network.rng
@@ -179,15 +179,7 @@
</element>
</optional>
<optional>
- <element name="driver">
- <attribute name="name">
- <choice>
- <value>kvm</value>
- <value>vfio</value>
- </choice>
- </attribute>
- <empty/>
- </element>
+ <ref name="hostdevDriver"/>
</optional>
<optional>
<element name="nat">
diff --git a/src/conf/schemas/networkport.rng b/src/conf/schemas/networkport.rng
index 14db949578..50995559e8 100644
--- a/src/conf/schemas/networkport.rng
+++ b/src/conf/schemas/networkport.rng
@@ -145,15 +145,7 @@
</optional>
<interleave>
<optional>
- <element name="driver">
- <attribute name="name">
- <choice>
- <value>kvm</value>
- <value>vfio</value>
- </choice>
- </attribute>
- <empty/>
- </element>
+ <ref name="hostdevDriver"/>
</optional>
<element name="address">
<ref name="pciaddress"/>
--
2.41.0
8:35 a.m.
New subject: [libvirt PATCH v2 02/15] schema: consolidate RNG for all hostdev
<driver> elements
On Mon, Nov 06, 2023 at 02:38:47 -0500, Laine Stump wrote:
The exact same element can appear in <hostdev> and
<interface
type='hostdev'>, and nearly identical in <network> and
<networkport>
(these latter two don't include "xen" as a possible driver, but that's
coincidental - there's no reason Xen couldn't also use the VF pools in
virtual networks, it just doesn't).
This patch modifies all 4 to use the same <ref name="hostdevDriver"/>
so that it is simpler to add something new.
A side effect of this patch is that the grammar for the <interface>
element in domain XML has been tightened up a bit - previously it was
accepted by the schema (but nonsensical) to have virtio and network
interface options specified; as a part of making the two different
<driver> choices each a complete element (rather than each being a
collection of attributes and subelements) these extra
attributes/subelements that were irrelevant to the hostdev-type
<driver> were made to be valid only for an emulated interface's
<driver>.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/schemas/basictypes.rng | 13 +++
src/conf/schemas/domaincommon.rng | 173 ++++++++++++++----------------
src/conf/schemas/network.rng | 10 +-
src/conf/schemas/networkport.rng | 10 +-
4 files changed, 94 insertions(+), 112 deletions(-)
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
1:38 a.m.
New subject: [libvirt PATCH v2 03/15] conf: move/rename hostdev PCI driver type enum to device_conf.h
Currently this enum is defined in domain_conf.h and named
virDomainHostdevSubsysPCIDriverType. I want to use it in parts of the
network and networkport config, so am moving its definition to
device_conf.h which is / can be included by all interested parties,
and renaming it to be less specific to its old usage (all the other
parts still apply, at least functionally, to the new usage). The name
change (which includes enum values) does cause a lot of churn, but
it's all mechanical.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/device_conf.c | 9 +++++++++
src/conf/device_conf.h | 12 +++++++++++
src/conf/domain_capabilities.c | 2 +-
src/conf/domain_capabilities.h | 2 +-
src/conf/domain_conf.c | 34 +++++++++++++-------------------
src/conf/domain_conf.h | 14 +------------
src/hypervisor/virhostdev.c | 8 ++++----
src/libvirt_private.syms | 2 +-
src/libxl/libxl_capabilities.c | 2 +-
src/libxl/libxl_domain.c | 6 +++---
src/libxl/libxl_driver.c | 4 ++--
src/qemu/qemu_capabilities.c | 4 ++--
src/qemu/qemu_command.c | 12 +++++------
src/qemu/qemu_domain.c | 23 ++++++++++-----------
src/qemu/qemu_validate.c | 2 +-
src/security/security_apparmor.c | 2 +-
src/security/security_dac.c | 4 ++--
src/security/security_selinux.c | 4 ++--
src/security/virt-aa-helper.c | 8 +++++---
tests/domaincapstest.c | 4 ++--
tests/virhostdevtest.c | 2 +-
tools/virsh-completer-nodedev.c | 4 ++--
22 files changed, 85 insertions(+), 79 deletions(-)
diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
index f3d977f2b7..25a522671e 100644
--- a/src/conf/device_conf.c
+++ b/src/conf/device_conf.c
@@ -29,6 +29,15 @@
#define VIR_FROM_THIS VIR_FROM_DEVICE
+VIR_ENUM_IMPL(virDeviceHostdevPCIDriver,
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST,
+ "default",
+ "kvm",
+ "vfio",
+ "xen",
+);
+
+
VIR_ENUM_IMPL(virDomainDeviceAddress,
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_LAST,
"none",
diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index a83377417a..7513beb5e1 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -31,6 +31,18 @@
#include "virnetdev.h"
#include "virenum.h"
+/* the backend driver used for PCI hostdev devices */
+typedef enum {
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT = 0, /* detect automatically, prefer VFIO
*/
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM, /* force legacy kvm style */
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO, /* force vfio */
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN, /* force legacy xen style, use pciback */
+
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST
+} virDeviceHostdevPCIDriverType;
+
+VIR_ENUM_DECL(virDeviceHostdevPCIDriver);
+
typedef enum {
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE = 0,
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI,
diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c
index f6e09dc584..6c1ccb2370 100644
--- a/src/conf/domain_capabilities.c
+++ b/src/conf/domain_capabilities.c
@@ -524,7 +524,7 @@ virDomainCapsDeviceHostdevFormat(virBuffer *buf,
ENUM_PROCESS(hostdev, startupPolicy, virDomainStartupPolicyTypeToString);
ENUM_PROCESS(hostdev, subsysType, virDomainHostdevSubsysTypeToString);
ENUM_PROCESS(hostdev, capsType, virDomainHostdevCapsTypeToString);
- ENUM_PROCESS(hostdev, pciBackend, virDomainHostdevSubsysPCIBackendTypeToString);
+ ENUM_PROCESS(hostdev, pciBackend, virDeviceHostdevPCIDriverTypeToString);
FORMAT_EPILOGUE(hostdev);
}
diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h
index 01bcfa2e39..25d3672b18 100644
--- a/src/conf/domain_capabilities.h
+++ b/src/conf/domain_capabilities.h
@@ -99,7 +99,7 @@ STATIC_ASSERT_ENUM(VIR_DOMAIN_HOSTDEV_MODE_LAST);
STATIC_ASSERT_ENUM(VIR_DOMAIN_STARTUP_POLICY_LAST);
STATIC_ASSERT_ENUM(VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_LAST);
STATIC_ASSERT_ENUM(VIR_DOMAIN_HOSTDEV_CAPS_TYPE_LAST);
-STATIC_ASSERT_ENUM(VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_LAST);
+STATIC_ASSERT_ENUM(VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST);
typedef struct _virDomainCapsDeviceHostdev virDomainCapsDeviceHostdev;
struct _virDomainCapsDeviceHostdev {
virTristateBool supported;
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index fa97def9f7..4a3de08efa 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -1053,13 +1053,6 @@ VIR_ENUM_IMPL(virDomainHostdevSubsys,
"mdev",
);
-VIR_ENUM_IMPL(virDomainHostdevSubsysPCIBackend,
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_LAST,
- "default",
- "kvm",
- "vfio",
- "xen",
-);
VIR_ENUM_IMPL(virDomainHostdevSubsysSCSIProtocol,
VIR_DOMAIN_HOSTDEV_SCSI_PROTOCOL_TYPE_LAST,
@@ -6276,7 +6269,7 @@ virDomainHostdevDefParseXMLSubsys(xmlNodePtr node,
driver_node = virXPathNode("./driver", ctxt);
if (virXMLPropEnum(driver_node, "name",
- virDomainHostdevSubsysPCIBackendTypeFromString,
+ virDeviceHostdevPCIDriverTypeFromString,
VIR_XML_PROP_NONZERO,
&pcisrc->backend) < 0)
return -1;
@@ -23342,8 +23335,9 @@ virDomainHostdevDefFormatSubsysPCI(virBuffer *buf,
virBufferAsprintf(&sourceAttrBuf, "
writeFiltering='%s'",
virTristateBoolTypeToString(def->writeFiltering));
- if (pcisrc->backend != VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT) {
- const char *backend =
virDomainHostdevSubsysPCIBackendTypeToString(pcisrc->backend);
+ if (pcisrc->backend != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
+ const char *backend
+ = virDeviceHostdevPCIDriverTypeToString(pcisrc->backend);
if (!backend) {
virReportError(VIR_ERR_INTERNAL_ERROR,
@@ -29841,17 +29835,17 @@ virDomainNetDefActualFromNetworkPort(virDomainNetDef *iface,
switch ((virNetworkForwardDriverNameType)port->plug.hostdevpci.driver) {
case VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT:
actual->data.hostdev.def.source.subsys.u.pci.backend =
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT;
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT;
break;
case VIR_NETWORK_FORWARD_DRIVER_NAME_KVM:
actual->data.hostdev.def.source.subsys.u.pci.backend =
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM;
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM;
break;
case VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO:
actual->data.hostdev.def.source.subsys.u.pci.backend =
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO;
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
break;
case VIR_NETWORK_FORWARD_DRIVER_NAME_LAST:
@@ -29962,26 +29956,26 @@ virDomainNetDefActualToNetworkPort(virDomainDef *dom,
port->plug.hostdevpci.managed =
virTristateBoolFromBool(actual->data.hostdev.def.managed);
port->plug.hostdevpci.addr =
actual->data.hostdev.def.source.subsys.u.pci.addr;
switch (actual->data.hostdev.def.source.subsys.u.pci.backend) {
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT:
port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT;
break;
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM:
port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_KVM;
break;
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO:
port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO;
break;
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN:
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("Unexpected PCI backend 'xen'"));
break;
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_LAST:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST:
default:
- virReportEnumRangeError(virDomainHostdevSubsysPCIBackendType,
+ virReportEnumRangeError(virDeviceHostdevPCIDriverType,
actual->data.hostdev.def.source.subsys.u.pci.backend);
return NULL;
}
@@ -30926,7 +30920,7 @@ virHostdevIsVFIODevice(const virDomainHostdevDef *hostdev)
{
return hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
- hostdev->source.subsys.u.pci.backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO;
+ hostdev->source.subsys.u.pci.backend ==
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
}
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 7c0e017038..57e06dd935 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -201,18 +201,6 @@ typedef enum {
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_LAST
} virDomainHostdevSubsysType;
-/* the backend driver used for PCI hostdev devices */
-typedef enum {
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT = 0, /* detect automatically, prefer VFIO */
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM, /* force legacy kvm style */
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO, /* force vfio */
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN, /* force legacy xen style, use pciback */
-
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_LAST
-} virDomainHostdevSubsysPCIBackendType;
-
-VIR_ENUM_DECL(virDomainHostdevSubsysPCIBackend);
-
typedef enum {
VIR_DOMAIN_HOSTDEV_SCSI_PROTOCOL_TYPE_NONE,
VIR_DOMAIN_HOSTDEV_SCSI_PROTOCOL_TYPE_ISCSI,
@@ -247,7 +235,7 @@ struct _virDomainHostdevSubsysUSB {
struct _virDomainHostdevSubsysPCI {
virPCIDeviceAddress addr; /* host address */
- virDomainHostdevSubsysPCIBackendType backend;
+ virDeviceHostdevPCIDriverType backend;
virBitmap *origstates;
};
diff --git a/src/hypervisor/virhostdev.c b/src/hypervisor/virhostdev.c
index 4672bd8785..ce7189ffcd 100644
--- a/src/hypervisor/virhostdev.c
+++ b/src/hypervisor/virhostdev.c
@@ -243,14 +243,14 @@ virHostdevGetPCIHostDevice(const virDomainHostdevDef *hostdev,
virPCIDeviceSetManaged(actual, hostdev->managed);
- if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO) {
+ if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
virPCIDeviceSetStubDriverType(actual, VIR_PCI_STUB_DRIVER_VFIO);
- } else if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN) {
+ } else if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN) {
virPCIDeviceSetStubDriverType(actual, VIR_PCI_STUB_DRIVER_XEN);
} else {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
- _("pci backend driver '%1$s' is not
supported"),
-
virDomainHostdevSubsysPCIBackendTypeToString(pcisrc->backend));
+ _("pci backend driver type '%1$s' is not
supported"),
+ virDeviceHostdevPCIDriverTypeToString(pcisrc->backend));
return -1;
}
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 553b01b8c0..479a69ed0b 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -126,6 +126,7 @@ virCPUModeTypeToString;
# conf/device_conf.h
virCCWDeviceAddressParseXML;
+virDeviceHostdevPCIDriverTypeToString;
virDeviceInfoPCIAddressExtensionIsPresent;
virDeviceInfoPCIAddressExtensionIsWanted;
virDeviceInfoPCIAddressIsPresent;
@@ -467,7 +468,6 @@ virDomainHostdevInsert;
virDomainHostdevMatch;
virDomainHostdevModeTypeToString;
virDomainHostdevRemove;
-virDomainHostdevSubsysPCIBackendTypeToString;
virDomainHostdevSubsysSCSIVHostModelTypeFromString;
virDomainHostdevSubsysSCSIVHostModelTypeToString;
virDomainHostdevSubsysTypeToString;
diff --git a/src/libxl/libxl_capabilities.c b/src/libxl/libxl_capabilities.c
index 177e8b988e..28330c4d36 100644
--- a/src/libxl/libxl_capabilities.c
+++ b/src/libxl/libxl_capabilities.c
@@ -631,7 +631,7 @@ libxlMakeDomainDeviceHostdevCaps(virDomainCapsDeviceHostdev *dev)
virDomainCapsEnumClear(&dev->pciBackend);
VIR_DOMAIN_CAPS_ENUM_SET(dev->pciBackend,
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN);
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN);
return 0;
}
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 0c4beffd6a..904f40914c 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -160,8 +160,8 @@ libxlDomainDeviceDefPostParse(virDomainDeviceDef *dev,
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI
&&
- pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT)
- pcisrc->backend = VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN;
+ pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
+ pcisrc->backend = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
}
if (dev->type == VIR_DOMAIN_DEVICE_VIDEO) {
@@ -997,7 +997,7 @@ libxlNetworkPrepareDevices(virDomainDef *def)
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
- pcisrc->backend = VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN;
+ pcisrc->backend = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
if (virDomainHostdevInsert(def, hostdev) < 0)
return -1;
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index c98d2d737a..d04ec7f6ea 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -3398,12 +3398,12 @@ libxlDomainAttachNetDevice(libxlDriverPrivate *driver,
virDomainHostdevSubsysPCI *pcisrc = &hostdev->source.subsys.u.pci;
/* For those just allocated from a network pool whose backend is
- * still VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT, we need to set
+ * still VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT, we need to set
* backend correctly.
*/
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
- pcisrc->backend = VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN;
+ pcisrc->backend = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
/* This is really a "smart hostdev", so it should be attached
* as a hostdev (the hostdev code will reach over into the
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 83119e871a..a5e2681ea1 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -6352,8 +6352,8 @@ virQEMUCapsFillDomainDeviceHostdevCaps(virQEMUCaps *qemuCaps,
if (supportsPassthroughVFIO &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VFIO_PCI)) {
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->pciBackend,
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT,
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO);
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT,
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO);
}
}
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 2674dd6959..3bcd0d3aa8 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -4712,16 +4712,16 @@ qemuBuildPCIHostdevDevProps(const virDomainDef *def,
/* caller has to assign proper passthrough backend type */
switch (pcisrc->backend) {
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO:
break;
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM:
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT:
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN:
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_LAST:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST:
virReportError(VIR_ERR_INTERNAL_ERROR,
_("invalid PCI passthrough type '%1$s'"),
-
virDomainHostdevSubsysPCIBackendTypeToString(pcisrc->backend));
+ virDeviceHostdevPCIDriverTypeToString(pcisrc->backend));
return NULL;
}
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index ae19ce884b..cf95b2cce3 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -10568,7 +10568,7 @@ qemuDomainGetHostdevPath(virDomainHostdevDef *dev,
case VIR_DOMAIN_HOSTDEV_MODE_SUBSYS:
switch (dev->source.subsys.type) {
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI:
- if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO) {
+ if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
if (!(tmpPath =
virPCIDeviceAddressGetIOMMUGroupDev(&pcisrc->addr)))
return -1;
@@ -11332,14 +11332,15 @@ qemuDomainPrepareHostdevPCI(virDomainHostdevDef *hostdev,
virQEMUCaps *qemuCaps)
{
bool supportsPassthroughVFIO = qemuHostdevHostSupportsPassthroughVFIO();
- virDomainHostdevSubsysPCIBackendType *backend =
&hostdev->source.subsys.u.pci.backend;
+ virDeviceHostdevPCIDriverType *driverType
+ = &hostdev->source.subsys.u.pci.backend;
/* assign defaults for hostdev passthrough */
- switch (*backend) {
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT:
+ switch (*driverType) {
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT:
if (supportsPassthroughVFIO) {
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VFIO_PCI)) {
- *backend = VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO;
+ *driverType = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
} else {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("VFIO PCI device assignment is not supported by
this version of QEMU"));
@@ -11352,7 +11353,7 @@ qemuDomainPrepareHostdevPCI(virDomainHostdevDef *hostdev,
}
break;
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO:
if (!supportsPassthroughVFIO) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("host doesn't support VFIO PCI
passthrough"));
@@ -11360,20 +11361,20 @@ qemuDomainPrepareHostdevPCI(virDomainHostdevDef *hostdev,
}
break;
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM:
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("host doesn't support legacy PCI passthrough"));
return false;
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN:
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN:
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("QEMU does not support device assignment mode
'%1$s'"),
- virDomainHostdevSubsysPCIBackendTypeToString(*backend));
+ virDeviceHostdevPCIDriverTypeToString(*driverType));
return false;
default:
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_LAST:
- virReportEnumRangeError(virDomainHostdevSubsysPCIBackendType, *backend);
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST:
+ virReportEnumRangeError(virDeviceHostdevPCIDriverType, *driverType);
break;
}
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 93df9e4c8e..83365f6685 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -2464,7 +2464,7 @@ qemuValidateDomainDeviceDefHostdev(const virDomainHostdevDef
*hostdev,
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI:
backend = hostdev->source.subsys.u.pci.backend;
- if (backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO) {
+ if (backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VFIO_PCI)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("VFIO PCI device assignment is not supported by
this version of qemu"));
diff --git a/src/security/security_apparmor.c b/src/security/security_apparmor.c
index 6fd0aedacf..515d68ec6b 100644
--- a/src/security/security_apparmor.c
+++ b/src/security/security_apparmor.c
@@ -869,7 +869,7 @@ AppArmorSetSecurityHostdevLabel(virSecurityManager *mgr,
if (!pci)
goto done;
- if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO) {
+ if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev) {
diff --git a/src/security/security_dac.c b/src/security/security_dac.c
index c07e488db7..ff28e17136 100644
--- a/src/security/security_dac.c
+++ b/src/security/security_dac.c
@@ -1257,7 +1257,7 @@ virSecurityDACSetHostdevLabel(virSecurityManager *mgr,
if (!pci)
return -1;
- if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO) {
+ if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
g_autofree char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev)
@@ -1418,7 +1418,7 @@ virSecurityDACRestoreHostdevLabel(virSecurityManager *mgr,
if (!pci)
return -1;
- if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO) {
+ if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
g_autofree char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev)
diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
index 84c5ce75ed..89ceaf48d7 100644
--- a/src/security/security_selinux.c
+++ b/src/security/security_selinux.c
@@ -2201,7 +2201,7 @@ virSecuritySELinuxSetHostdevSubsysLabel(virSecurityManager *mgr,
if (!pci)
return -1;
- if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO) {
+ if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
g_autofree char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev)
@@ -2437,7 +2437,7 @@ virSecuritySELinuxRestoreHostdevSubsysLabel(virSecurityManager
*mgr,
if (!pci)
return -1;
- if (pcisrc->backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO) {
+ if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
g_autofree char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev)
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c
index be13979cef..ac4225a783 100644
--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -1092,9 +1092,11 @@ get_files(vahControl * ctl)
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: {
virPCIDevice *pci =
virPCIDeviceNew(&dev->source.subsys.u.pci.addr);
- virDomainHostdevSubsysPCIBackendType backend =
dev->source.subsys.u.pci.backend;
- if (backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO ||
- backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT) {
+ virDeviceHostdevPCIDriverType driverType
+ = dev->source.subsys.u.pci.backend;
+
+ if (driverType == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO ||
+ driverType == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
needsVfio = true;
}
diff --git a/tests/domaincapstest.c b/tests/domaincapstest.c
index c4a4508430..3d86bdb9c7 100644
--- a/tests/domaincapstest.c
+++ b/tests/domaincapstest.c
@@ -109,8 +109,8 @@ fillQemuCaps(virDomainCaps *domCaps,
* successfully mocked as they are not exposed as internal APIs. Therefore,
* instead of mocking set the expected values here by hand. */
VIR_DOMAIN_CAPS_ENUM_SET(domCaps->hostdev.pciBackend,
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT,
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO);
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT,
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO);
/* As of f05b6a918e28 we are expecting to see OVMF_CODE.fd file which
* may not exists everywhere. */
diff --git a/tests/virhostdevtest.c b/tests/virhostdevtest.c
index 04e6c00908..d9ff992e91 100644
--- a/tests/virhostdevtest.c
+++ b/tests/virhostdevtest.c
@@ -134,7 +134,7 @@ myInit(void)
subsys->u.pci.addr.bus = 0;
subsys->u.pci.addr.slot = i + 1;
subsys->u.pci.addr.function = 0;
- subsys->u.pci.backend = VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO;
+ subsys->u.pci.backend = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
}
for (i = 0; i < nhostdevs; i++) {
diff --git a/tools/virsh-completer-nodedev.c b/tools/virsh-completer-nodedev.c
index d743df460e..1518395a1e 100644
--- a/tools/virsh-completer-nodedev.c
+++ b/tools/virsh-completer-nodedev.c
@@ -110,6 +110,6 @@ virshNodeDevicePCIBackendCompleter(vshControl *ctl G_GNUC_UNUSED,
{
virCheckFlags(0, NULL);
- return virshEnumComplete(VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_LAST,
- virDomainHostdevSubsysPCIBackendTypeToString);
+ return virshEnumComplete(VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST,
+ virDeviceHostdevPCIDriverTypeToString);
}
--
2.41.0
8:41 a.m.
New subject: [libvirt PATCH v2 03/15] conf: move/rename hostdev PCI driver
type enum to device_conf.h
On Mon, Nov 06, 2023 at 02:38:48 -0500, Laine Stump wrote:
Currently this enum is defined in domain_conf.h and named
virDomainHostdevSubsysPCIDriverType. I want to use it in parts of the
network and networkport config, so am moving its definition to
device_conf.h which is / can be included by all interested parties,
and renaming it to be less specific to its old usage (all the other
parts still apply, at least functionally, to the new usage). The name
change (which includes enum values) does cause a lot of churn, but
it's all mechanical.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
[...]
@@ -23342,8 +23335,9 @@ virDomainHostdevDefFormatSubsysPCI(virBuffer
*buf,
virBufferAsprintf(&sourceAttrBuf, "
writeFiltering='%s'",
virTristateBoolTypeToString(def->writeFiltering));
- if (pcisrc->backend != VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT) {
- const char *backend =
virDomainHostdevSubsysPCIBackendTypeToString(pcisrc->backend);
+ if (pcisrc->backend != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
+ const char *backend
+ = virDeviceHostdevPCIDriverTypeToString(pcisrc->backend);
Please no pointless linebreaks. The times of max 80 colums are gone.
if (!backend) {
virReportError(VIR_ERR_INTERNAL_ERROR,
@@ -29841,17 +29835,17 @@ virDomainNetDefActualFromNetworkPort(virDomainNetDef *iface,
switch ((virNetworkForwardDriverNameType)port->plug.hostdevpci.driver) {
case VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT:
actual->data.hostdev.def.source.subsys.u.pci.backend =
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT;
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT;
break;
case VIR_NETWORK_FORWARD_DRIVER_NAME_KVM:
actual->data.hostdev.def.source.subsys.u.pci.backend =
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM;
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM;
break;
case VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO:
actual->data.hostdev.def.source.subsys.u.pci.backend =
- VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO;
+ VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
break;
I'd argue that the above is in the same category now that you are
changing it.
[...]
@@ -11332,14 +11332,15 @@
qemuDomainPrepareHostdevPCI(virDomainHostdevDef *hostdev,
virQEMUCaps *qemuCaps)
{
bool supportsPassthroughVFIO = qemuHostdevHostSupportsPassthroughVFIO();
- virDomainHostdevSubsysPCIBackendType *backend =
&hostdev->source.subsys.u.pci.backend;
+ virDeviceHostdevPCIDriverType *driverType
+ = &hostdev->source.subsys.u.pci.backend;
Same.
/* assign defaults for hostdev passthrough */
- switch (*backend) {
- case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT:
+ switch (*driverType) {
+ case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT:
if (supportsPassthroughVFIO) {
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VFIO_PCI)) {
- *backend = VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO;
+ *driverType = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
} else {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("VFIO PCI device assignment is not supported by
this version of QEMU"));
[...]
diff --git a/src/security/virt-aa-helper.c
b/src/security/virt-aa-helper.c
index be13979cef..ac4225a783 100644
--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -1092,9 +1092,11 @@ get_files(vahControl * ctl)
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: {
virPCIDevice *pci =
virPCIDeviceNew(&dev->source.subsys.u.pci.addr);
- virDomainHostdevSubsysPCIBackendType backend =
dev->source.subsys.u.pci.backend;
- if (backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO ||
- backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT) {
+ virDeviceHostdevPCIDriverType driverType
+ = dev->source.subsys.u.pci.backend;
ditto
+
+ if (driverType == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO ||
+ driverType == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
needsVfio = true;
}
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
12:32 p.m.
New subject: [libvirt PATCH v2 03/15] conf: move/rename hostdev PCI driver
type enum to device_conf.h
On 11/27/23 9:41 AM, Peter Krempa wrote:
On Mon, Nov 06, 2023 at 02:38:48 -0500, Laine Stump wrote:
> Currently this enum is defined in domain_conf.h and named
> virDomainHostdevSubsysPCIDriverType. I want to use it in parts of the
> network and networkport config, so am moving its definition to
> device_conf.h which is / can be included by all interested parties,
> and renaming it to be less specific to its old usage (all the other
> parts still apply, at least functionally, to the new usage). The name
> change (which includes enum values) does cause a lot of churn, but
> it's all mechanical.
>
> Signed-off-by: Laine Stump <laine(a)redhat.com>
> ---
[...]
> @@ -23342,8 +23335,9 @@ virDomainHostdevDefFormatSubsysPCI(virBuffer *buf,
> virBufferAsprintf(&sourceAttrBuf, "
writeFiltering='%s'",
>
virTristateBoolTypeToString(def->writeFiltering));
>
> - if (pcisrc->backend != VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT) {
> - const char *backend =
virDomainHostdevSubsysPCIBackendTypeToString(pcisrc->backend);
> + if (pcisrc->backend != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
> + const char *backend
> + = virDeviceHostdevPCIDriverTypeToString(pcisrc->backend);
Please no pointless linebreaks. The times of max 80 colums are gone.
But what about this onion on my belt?
Old habits die hard, but I'll fix all of these. Are you okay with the
currently listed 100 character limit? Or do you think there should be
*no* line length limit?
4:46 a.m.
New subject: [libvirt PATCH v2 03/15] conf: move/rename hostdev PCI driver
type enum to device_conf.h
On Fri, Dec 08, 2023 at 13:32:31 -0500, Laine Stump wrote:
On 11/27/23 9:41 AM, Peter Krempa wrote:
> On Mon, Nov 06, 2023 at 02:38:48 -0500, Laine Stump wrote:
> > Currently this enum is defined in domain_conf.h and named
> > virDomainHostdevSubsysPCIDriverType. I want to use it in parts of the
> > network and networkport config, so am moving its definition to
> > device_conf.h which is / can be included by all interested parties,
> > and renaming it to be less specific to its old usage (all the other
> > parts still apply, at least functionally, to the new usage). The name
> > change (which includes enum values) does cause a lot of churn, but
> > it's all mechanical.
> >
> > Signed-off-by: Laine Stump <laine(a)redhat.com>
> > ---
>
> [...]
>
>
> > @@ -23342,8 +23335,9 @@ virDomainHostdevDefFormatSubsysPCI(virBuffer *buf,
> > virBufferAsprintf(&sourceAttrBuf, "
writeFiltering='%s'",
> >
virTristateBoolTypeToString(def->writeFiltering));
> > - if (pcisrc->backend != VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT) {
> > - const char *backend =
virDomainHostdevSubsysPCIBackendTypeToString(pcisrc->backend);
> > + if (pcisrc->backend != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
> > + const char *backend
> > + = virDeviceHostdevPCIDriverTypeToString(pcisrc->backend);
>
> Please no pointless linebreaks. The times of max 80 colums are gone.
But what about this onion on my belt?
Old habits die hard, but I'll fix all of these. Are you okay with the
currently listed 100 character limit? Or do you think there should be *no*
line length limit?
Having a specific number leads to stuff like this. I'd prefer we stay at
just stating that lines should be reasonably long without breaking
coding style while maintaining readability. Once the line gets
ridiculously long it's usually obvious to many that it's not a good
idea.
1:38 a.m.
New subject: [libvirt PATCH v2 04/15] conf: normalize hostdev <driver> parsing to simplify adding new attr
The hostdev version of the <driver> subelement appears in four places:
* The domain XML in the <hostdev> and <interface type='hostdev'>
elements (that's 2)
* The network XML inside <forward> when the network is a pool of
SRIOV VFs
* the <networkport> XML, which is used to communicate between the
hypervisor driver and network driver.
In order to make the pending addition of a new attribute to <driver>
in all these cases simpler, this patch refactors the parsing of
<driver> in all four places to use virXMLProp*() and
virXMLFormatElement().
Making all of the different instances of the separate parse/format for
<driver> look nearly identical will make it easier to see that the
upcoming patch that converges all four to use a common
parser/formatter is a functional NOP.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/domain_conf.c | 28 ++++++++++++++++------------
src/conf/network_conf.c | 26 ++++++++++++--------------
src/conf/network_conf.h | 2 +-
src/conf/virnetworkportdef.c | 28 ++++++++++++++++++----------
src/conf/virnetworkportdef.h | 2 +-
5 files changed, 48 insertions(+), 38 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 4a3de08efa..1d3e46604a 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -6267,13 +6267,14 @@ virDomainHostdevDefParseXMLSubsys(xmlNodePtr node,
if (virDomainHostdevSubsysPCIDefParseXML(sourcenode, ctxt, def, flags) < 0)
return -1;
- driver_node = virXPathNode("./driver", ctxt);
- if (virXMLPropEnum(driver_node, "name",
- virDeviceHostdevPCIDriverTypeFromString,
- VIR_XML_PROP_NONZERO,
- &pcisrc->backend) < 0)
- return -1;
-
+ if ((driver_node = virXPathNode("./driver", ctxt))) {
+ if (virXMLPropEnum(driver_node, "name",
+ virDeviceHostdevPCIDriverTypeFromString,
+ VIR_XML_PROP_NONZERO,
+ &pcisrc->backend) < 0) {
+ return -1;
+ }
+ }
break;
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_USB:
@@ -23327,14 +23328,11 @@ virDomainHostdevDefFormatSubsysPCI(virBuffer *buf,
unsigned int flags,
bool includeTypeInAddr)
{
+ g_auto(virBuffer) driverAttrBuf = VIR_BUFFER_INITIALIZER;
g_auto(virBuffer) sourceAttrBuf = VIR_BUFFER_INITIALIZER;
g_auto(virBuffer) sourceChildBuf = VIR_BUFFER_INIT_CHILD(buf);
virDomainHostdevSubsysPCI *pcisrc = &def->source.subsys.u.pci;
- if (def->writeFiltering != VIR_TRISTATE_BOOL_ABSENT)
- virBufferAsprintf(&sourceAttrBuf, "
writeFiltering='%s'",
- virTristateBoolTypeToString(def->writeFiltering));
-
if (pcisrc->backend != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
const char *backend
= virDeviceHostdevPCIDriverTypeToString(pcisrc->backend);
@@ -23346,9 +23344,15 @@ virDomainHostdevDefFormatSubsysPCI(virBuffer *buf,
return -1;
}
- virBufferAsprintf(buf, "<driver name='%s'/>\n",
backend);
+ virBufferAsprintf(&driverAttrBuf, " name='%s'", backend);
}
+ virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
+
+ if (def->writeFiltering != VIR_TRISTATE_BOOL_ABSENT)
+ virBufferAsprintf(&sourceAttrBuf, "
writeFiltering='%s'",
+ virTristateBoolTypeToString(def->writeFiltering));
+
virPCIDeviceAddressFormat(&sourceChildBuf, pcisrc->addr, includeTypeInAddr);
if (pcisrc->origstates &&
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index 1a6fd86180..b9601cb307 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -1334,8 +1334,8 @@ virNetworkForwardDefParseXML(const char *networkName,
g_autofree xmlNodePtr *forwardNatNodes = NULL;
g_autofree char *forwardDev = NULL;
g_autofree char *forwardManaged = NULL;
- g_autofree char *forwardDriverName = NULL;
g_autofree char *type = NULL;
+ xmlNodePtr driverNode = NULL;
VIR_XPATH_NODE_AUTORESTORE(ctxt)
ctxt->node = node;
@@ -1356,18 +1356,13 @@ virNetworkForwardDefParseXML(const char *networkName,
def->managed = true;
}
- forwardDriverName = virXPathString("string(./driver/@name)", ctxt);
- if (forwardDriverName) {
- int driverName
- = virNetworkForwardDriverNameTypeFromString(forwardDriverName);
-
- if (driverName <= 0) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
- _("Unknown forward <driver name='%1$s'/> in
network %2$s"),
- forwardDriverName, networkName);
+ if ((driverNode = virXPathNode("./driver", ctxt))) {
+ if (virXMLPropEnum(driverNode, "name",
+ virNetworkForwardDriverNameTypeFromString,
+ VIR_XML_PROP_NONZERO,
+ &def->driverName) < 0) {
return -1;
}
- def->driverName = driverName;
}
/* bridge and hostdev modes can use a pool of physical interfaces */
@@ -2331,6 +2326,7 @@ virNetworkDefFormatBuf(virBuffer *buf,
if (def->forward.type != VIR_NETWORK_FORWARD_NONE) {
const char *dev = NULL;
const char *mode = virNetworkForwardTypeToString(def->forward.type);
+ g_auto(virBuffer) driverAttrBuf = VIR_BUFFER_INITIALIZER;
if (!def->forward.npfs)
dev = virNetworkDefForwardIf(def, 0);
@@ -2361,8 +2357,7 @@ virNetworkDefFormatBuf(virBuffer *buf,
virBufferAsprintf(buf, "%s>\n", shortforward ? "/" :
"");
virBufferAdjustIndent(buf, 2);
- if (def->forward.driverName
- != VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT) {
+ if (def->forward.driverName) {
const char *driverName
= virNetworkForwardDriverNameTypeToString(def->forward.driverName);
if (!driverName) {
@@ -2371,8 +2366,11 @@ virNetworkDefFormatBuf(virBuffer *buf,
def->forward.driverName);
return -1;
}
- virBufferAsprintf(buf, "<driver name='%s'/>\n",
driverName);
+ virBufferAsprintf(&driverAttrBuf, " name='%s'",
driverName);
}
+
+ virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
+
if (def->forward.type == VIR_NETWORK_FORWARD_NAT) {
if (virNetworkForwardNatDefFormat(buf, &def->forward) < 0)
return -1;
diff --git a/src/conf/network_conf.h b/src/conf/network_conf.h
index 5a1bdb1284..497ae765f2 100644
--- a/src/conf/network_conf.h
+++ b/src/conf/network_conf.h
@@ -216,7 +216,7 @@ typedef struct _virNetworkForwardDef virNetworkForwardDef;
struct _virNetworkForwardDef {
int type; /* One of virNetworkForwardType constants */
bool managed; /* managed attribute for hostdev mode */
- int driverName; /* enum virNetworkForwardDriverNameType */
+ virNetworkForwardDriverNameType driverName;
/* If there are multiple forward devices (i.e. a pool of
* interfaces), they will be listed here.
diff --git a/src/conf/virnetworkportdef.c b/src/conf/virnetworkportdef.c
index fc06ef41d5..402c0051ec 100644
--- a/src/conf/virnetworkportdef.c
+++ b/src/conf/virnetworkportdef.c
@@ -87,10 +87,10 @@ virNetworkPortDefParseXML(xmlXPathContextPtr ctxt)
xmlNodePtr addressNode;
xmlNodePtr rxfiltersNode = NULL;
xmlNodePtr plugNode = NULL;
+ xmlNodePtr driverNode = NULL;
g_autofree char *mac = NULL;
g_autofree char *macmgr = NULL;
g_autofree char *mode = NULL;
- g_autofree char *driver = NULL;
def = g_new0(virNetworkPortDef, 1);
@@ -223,14 +223,16 @@ virNetworkPortDefParseXML(xmlXPathContextPtr ctxt)
VIR_XML_PROP_NONE,
&def->plug.hostdevpci.managed) < 0)
return NULL;
- driver = virXPathString("string(./plug/driver/@name)", ctxt);
- if (driver &&
- (def->plug.hostdevpci.driver =
- virNetworkForwardDriverNameTypeFromString(driver)) <= 0) {
- virReportError(VIR_ERR_XML_ERROR, "%s",
- _("Missing network port driver name"));
- return NULL;
+
+ if ((driverNode = virXPathNode("./plug/driver", ctxt))) {
+ if (virXMLPropEnum(driverNode, "name",
+ virNetworkForwardDriverNameTypeFromString,
+ VIR_XML_PROP_NONZERO,
+ &def->plug.hostdevpci.driver) < 0) {
+ return NULL;
+ }
}
+
if (!(addressNode = virXPathNode("./plug/address", ctxt))) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("Missing network port PCI address"));
@@ -319,6 +321,8 @@ virNetworkPortDefFormatBuf(virBuffer *buf,
virTristateBoolTypeToString(def->trustGuestRxFilters));
if (def->plugtype != VIR_NETWORK_PORT_PLUG_TYPE_NONE) {
+ g_auto(virBuffer) driverAttrBuf = VIR_BUFFER_INITIALIZER;
+
virBufferAsprintf(buf, "<plug type='%s'",
virNetworkPortPlugTypeToString(def->plugtype));
@@ -351,10 +355,14 @@ virNetworkPortDefFormatBuf(virBuffer *buf,
}
virBufferAddLit(buf, ">\n");
virBufferAdjustIndent(buf, 2);
- if (def->plug.hostdevpci.driver)
- virBufferEscapeString(buf, "<driver
name='%s'/>\n",
+
+ if (def->plug.hostdevpci.driver) {
+ virBufferEscapeString(&driverAttrBuf, "
name='%s'",
virNetworkForwardDriverNameTypeToString(
def->plug.hostdevpci.driver));
+ }
+
+ virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
virPCIDeviceAddressFormat(buf, def->plug.hostdevpci.addr, false);
virBufferAdjustIndent(buf, -2);
diff --git a/src/conf/virnetworkportdef.h b/src/conf/virnetworkportdef.h
index 48e73dbefd..bfe1dae9ea 100644
--- a/src/conf/virnetworkportdef.h
+++ b/src/conf/virnetworkportdef.h
@@ -69,7 +69,7 @@ struct _virNetworkPortDef {
} direct;
struct {
virPCIDeviceAddress addr; /* PCI Address of device */
- int driver; /* virNetworkForwardDriverNameType */
+ unsigned int driver; /* virNetworkForwardDriverNameType */
virTristateBool managed;
} hostdevpci;
} plug;
--
2.41.0
8:47 a.m.
New subject: [libvirt PATCH v2 04/15] conf: normalize hostdev <driver>
parsing to simplify adding new attr
On Mon, Nov 06, 2023 at 02:38:49 -0500, Laine Stump wrote:
The hostdev version of the <driver> subelement appears in four
places:
* The domain XML in the <hostdev> and <interface type='hostdev'>
elements (that's 2)
* The network XML inside <forward> when the network is a pool of
SRIOV VFs
* the <networkport> XML, which is used to communicate between the
hypervisor driver and network driver.
In order to make the pending addition of a new attribute to <driver>
in all these cases simpler, this patch refactors the parsing of
<driver> in all four places to use virXMLProp*() and
virXMLFormatElement().
Making all of the different instances of the separate parse/format for
<driver> look nearly identical will make it easier to see that the
upcoming patch that converges all four to use a common
parser/formatter is a functional NOP.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/domain_conf.c | 28 ++++++++++++++++------------
src/conf/network_conf.c | 26 ++++++++++++--------------
src/conf/network_conf.h | 2 +-
src/conf/virnetworkportdef.c | 28 ++++++++++++++++++----------
src/conf/virnetworkportdef.h | 2 +-
5 files changed, 48 insertions(+), 38 deletions(-)
[...]
@@ -351,10 +355,14 @@ virNetworkPortDefFormatBuf(virBuffer *buf,
}
virBufferAddLit(buf, ">\n");
virBufferAdjustIndent(buf, 2);
- if (def->plug.hostdevpci.driver)
- virBufferEscapeString(buf, "<driver
name='%s'/>\n",
+
+ if (def->plug.hostdevpci.driver) {
+ virBufferEscapeString(&driverAttrBuf, "
name='%s'",
virNetworkForwardDriverNameTypeToString(
def->plug.hostdevpci.driver));
Please remove the linebreak;
+ }
+
+ virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
virPCIDeviceAddressFormat(buf, def->plug.hostdevpci.addr, false);
virBufferAdjustIndent(buf, -2);
diff --git a/src/conf/virnetworkportdef.h b/src/conf/virnetworkportdef.h
index 48e73dbefd..bfe1dae9ea 100644
--- a/src/conf/virnetworkportdef.h
+++ b/src/conf/virnetworkportdef.h
@@ -69,7 +69,7 @@ struct _virNetworkPortDef {
} direct;
struct {
virPCIDeviceAddress addr; /* PCI Address of device */
- int driver; /* virNetworkForwardDriverNameType */
+ unsigned int driver; /* virNetworkForwardDriverNameType */
Use the proper enum type here.
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
1:38 a.m.
New subject: [libvirt PATCH v2 05/15] conf: put hostdev PCI backend into a struct
The new struct is virDeviceHostdevPCIDriverInfo, and the "backend"
enum in the hostdevDef will be replaced with a
virDeviceHostdevPCIDriverInfo named "driver'. Since the enum value in
this new struct is called "type", it means that all references to
"backend" will become "driver.type".
This will allow easily adding other items for new attributes in the
<driver> element / C struct, which will be useful once we are using
this new struct in multiple places.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/device_conf.h | 4 ++++
src/conf/domain_conf.c | 32 ++++++++++++++------------------
src/conf/domain_conf.h | 2 +-
src/conf/virconftypes.h | 2 ++
src/hypervisor/virhostdev.c | 6 +++---
src/libxl/libxl_domain.c | 6 +++---
src/libxl/libxl_driver.c | 6 +++---
src/qemu/qemu_command.c | 4 ++--
src/qemu/qemu_domain.c | 4 ++--
src/qemu/qemu_validate.c | 6 +++---
src/security/security_apparmor.c | 2 +-
src/security/security_dac.c | 4 ++--
src/security/security_selinux.c | 4 ++--
src/security/virt-aa-helper.c | 2 +-
tests/virhostdevtest.c | 2 +-
15 files changed, 44 insertions(+), 42 deletions(-)
diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index 7513beb5e1..3a7a6c3f99 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -43,6 +43,10 @@ typedef enum {
VIR_ENUM_DECL(virDeviceHostdevPCIDriver);
+struct _virDeviceHostdevPCIDriverInfo {
+ virDeviceHostdevPCIDriverType type;
+};
+
typedef enum {
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE = 0,
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI,
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 1d3e46604a..e322f1ffa7 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -6271,7 +6271,7 @@ virDomainHostdevDefParseXMLSubsys(xmlNodePtr node,
if (virXMLPropEnum(driver_node, "name",
virDeviceHostdevPCIDriverTypeFromString,
VIR_XML_PROP_NONZERO,
- &pcisrc->backend) < 0) {
+ &pcisrc->driver.type) < 0) {
return -1;
}
}
@@ -23333,18 +23333,18 @@ virDomainHostdevDefFormatSubsysPCI(virBuffer *buf,
g_auto(virBuffer) sourceChildBuf = VIR_BUFFER_INIT_CHILD(buf);
virDomainHostdevSubsysPCI *pcisrc = &def->source.subsys.u.pci;
- if (pcisrc->backend != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
- const char *backend
- = virDeviceHostdevPCIDriverTypeToString(pcisrc->backend);
+ if (pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
+ const char *driverType
+ = virDeviceHostdevPCIDriverTypeToString(pcisrc->driver.type);
- if (!backend) {
+ if (!driverType) {
virReportError(VIR_ERR_INTERNAL_ERROR,
- _("unexpected pci hostdev driver name type %1$d"),
- pcisrc->backend);
+ _("unexpected pci hostdev driver type %1$d"),
+ pcisrc->driver.type);
return -1;
}
- virBufferAsprintf(&driverAttrBuf, " name='%s'", backend);
+ virBufferAsprintf(&driverAttrBuf, " name='%s'",
driverType);
}
virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
@@ -29838,17 +29838,17 @@ virDomainNetDefActualFromNetworkPort(virDomainNetDef *iface,
actual->data.hostdev.def.source.subsys.u.pci.addr =
port->plug.hostdevpci.addr;
switch ((virNetworkForwardDriverNameType)port->plug.hostdevpci.driver) {
case VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT:
- actual->data.hostdev.def.source.subsys.u.pci.backend =
+ actual->data.hostdev.def.source.subsys.u.pci.driver.type =
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT;
break;
case VIR_NETWORK_FORWARD_DRIVER_NAME_KVM:
- actual->data.hostdev.def.source.subsys.u.pci.backend =
+ actual->data.hostdev.def.source.subsys.u.pci.driver.type =
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM;
break;
case VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO:
- actual->data.hostdev.def.source.subsys.u.pci.backend =
+ actual->data.hostdev.def.source.subsys.u.pci.driver.type =
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
break;
@@ -29959,7 +29959,7 @@ virDomainNetDefActualToNetworkPort(virDomainDef *dom,
}
port->plug.hostdevpci.managed =
virTristateBoolFromBool(actual->data.hostdev.def.managed);
port->plug.hostdevpci.addr =
actual->data.hostdev.def.source.subsys.u.pci.addr;
- switch (actual->data.hostdev.def.source.subsys.u.pci.backend) {
+ switch (actual->data.hostdev.def.source.subsys.u.pci.driver.type) {
case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT:
port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT;
break;
@@ -29973,14 +29973,10 @@ virDomainNetDefActualToNetworkPort(virDomainDef *dom,
break;
case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN:
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("Unexpected PCI backend 'xen'"));
- break;
-
case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST:
default:
virReportEnumRangeError(virDeviceHostdevPCIDriverType,
-
actual->data.hostdev.def.source.subsys.u.pci.backend);
+
actual->data.hostdev.def.source.subsys.u.pci.driver.type);
return NULL;
}
@@ -30924,7 +30920,7 @@ virHostdevIsVFIODevice(const virDomainHostdevDef *hostdev)
{
return hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
- hostdev->source.subsys.u.pci.backend ==
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
+ hostdev->source.subsys.u.pci.driver.type ==
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
}
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 57e06dd935..855e09d236 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -235,7 +235,7 @@ struct _virDomainHostdevSubsysUSB {
struct _virDomainHostdevSubsysPCI {
virPCIDeviceAddress addr; /* host address */
- virDeviceHostdevPCIDriverType backend;
+ virDeviceHostdevPCIDriverInfo driver;
virBitmap *origstates;
};
diff --git a/src/conf/virconftypes.h b/src/conf/virconftypes.h
index 26cb966194..0779bc224b 100644
--- a/src/conf/virconftypes.h
+++ b/src/conf/virconftypes.h
@@ -66,6 +66,8 @@ typedef struct _virCapsHostSecModelLabel virCapsHostSecModelLabel;
typedef struct _virCapsStoragePool virCapsStoragePool;
+typedef struct _virDeviceHostdevPCIDriverInfo virDeviceHostdevPCIDriverInfo;
+
typedef struct _virDomainABIStability virDomainABIStability;
typedef struct _virDomainActualNetDef virDomainActualNetDef;
diff --git a/src/hypervisor/virhostdev.c b/src/hypervisor/virhostdev.c
index ce7189ffcd..a33b3b604f 100644
--- a/src/hypervisor/virhostdev.c
+++ b/src/hypervisor/virhostdev.c
@@ -243,14 +243,14 @@ virHostdevGetPCIHostDevice(const virDomainHostdevDef *hostdev,
virPCIDeviceSetManaged(actual, hostdev->managed);
- if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
+ if (pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
virPCIDeviceSetStubDriverType(actual, VIR_PCI_STUB_DRIVER_VFIO);
- } else if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN) {
+ } else if (pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN) {
virPCIDeviceSetStubDriverType(actual, VIR_PCI_STUB_DRIVER_XEN);
} else {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("pci backend driver type '%1$s' is not
supported"),
- virDeviceHostdevPCIDriverTypeToString(pcisrc->backend));
+ virDeviceHostdevPCIDriverTypeToString(pcisrc->driver.type));
return -1;
}
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 904f40914c..22482adfa6 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -160,8 +160,8 @@ libxlDomainDeviceDefPostParse(virDomainDeviceDef *dev,
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI
&&
- pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
- pcisrc->backend = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
+ pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
+ pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
}
if (dev->type == VIR_DOMAIN_DEVICE_VIDEO) {
@@ -997,7 +997,7 @@ libxlNetworkPrepareDevices(virDomainDef *def)
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
- pcisrc->backend = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
+ pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
if (virDomainHostdevInsert(def, hostdev) < 0)
return -1;
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index d04ec7f6ea..7f12b11b8d 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -3397,13 +3397,13 @@ libxlDomainAttachNetDevice(libxlDriverPrivate *driver,
virDomainHostdevDef *hostdev = virDomainNetGetActualHostdev(net);
virDomainHostdevSubsysPCI *pcisrc = &hostdev->source.subsys.u.pci;
- /* For those just allocated from a network pool whose backend is
+ /* For those just allocated from a network pool whose driver type is
* still VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT, we need to set
- * backend correctly.
+ * driver type correctly.
*/
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
- pcisrc->backend = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
+ pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
/* This is really a "smart hostdev", so it should be attached
* as a hostdev (the hostdev code will reach over into the
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 3bcd0d3aa8..5847d5549d 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -4711,7 +4711,7 @@ qemuBuildPCIHostdevDevProps(const virDomainDef *def,
const char *failover_pair_id = NULL;
/* caller has to assign proper passthrough backend type */
- switch (pcisrc->backend) {
+ switch (pcisrc->driver.type) {
case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO:
break;
@@ -4721,7 +4721,7 @@ qemuBuildPCIHostdevDevProps(const virDomainDef *def,
case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST:
virReportError(VIR_ERR_INTERNAL_ERROR,
_("invalid PCI passthrough type '%1$s'"),
- virDeviceHostdevPCIDriverTypeToString(pcisrc->backend));
+ virDeviceHostdevPCIDriverTypeToString(pcisrc->driver.type));
return NULL;
}
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index cf95b2cce3..09735ba710 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -10568,7 +10568,7 @@ qemuDomainGetHostdevPath(virDomainHostdevDef *dev,
case VIR_DOMAIN_HOSTDEV_MODE_SUBSYS:
switch (dev->source.subsys.type) {
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI:
- if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
+ if (pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
if (!(tmpPath =
virPCIDeviceAddressGetIOMMUGroupDev(&pcisrc->addr)))
return -1;
@@ -11333,7 +11333,7 @@ qemuDomainPrepareHostdevPCI(virDomainHostdevDef *hostdev,
{
bool supportsPassthroughVFIO = qemuHostdevHostSupportsPassthroughVFIO();
virDeviceHostdevPCIDriverType *driverType
- = &hostdev->source.subsys.u.pci.backend;
+ = &hostdev->source.subsys.u.pci.driver.type;
/* assign defaults for hostdev passthrough */
switch (*driverType) {
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 83365f6685..d958d01638 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -2437,7 +2437,7 @@ qemuValidateDomainDeviceDefHostdev(const virDomainHostdevDef
*hostdev,
const virDomainDef *def,
virQEMUCaps *qemuCaps)
{
- int backend;
+ virDeviceHostdevPCIDriverType driverType;
/* forbid capabilities mode hostdev in this kind of hypervisor */
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_CAPABILITIES) {
@@ -2462,9 +2462,9 @@ qemuValidateDomainDeviceDefHostdev(const virDomainHostdevDef
*hostdev,
break;
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI:
- backend = hostdev->source.subsys.u.pci.backend;
+ driverType = hostdev->source.subsys.u.pci.driver.type;
- if (backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
+ if (driverType == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VFIO_PCI)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("VFIO PCI device assignment is not supported by
this version of qemu"));
diff --git a/src/security/security_apparmor.c b/src/security/security_apparmor.c
index 515d68ec6b..5ccc294773 100644
--- a/src/security/security_apparmor.c
+++ b/src/security/security_apparmor.c
@@ -869,7 +869,7 @@ AppArmorSetSecurityHostdevLabel(virSecurityManager *mgr,
if (!pci)
goto done;
- if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
+ if (pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev) {
diff --git a/src/security/security_dac.c b/src/security/security_dac.c
index ff28e17136..31997474a4 100644
--- a/src/security/security_dac.c
+++ b/src/security/security_dac.c
@@ -1257,7 +1257,7 @@ virSecurityDACSetHostdevLabel(virSecurityManager *mgr,
if (!pci)
return -1;
- if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
+ if (pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
g_autofree char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev)
@@ -1418,7 +1418,7 @@ virSecurityDACRestoreHostdevLabel(virSecurityManager *mgr,
if (!pci)
return -1;
- if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
+ if (pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
g_autofree char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev)
diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
index 89ceaf48d7..9a65c3a9f1 100644
--- a/src/security/security_selinux.c
+++ b/src/security/security_selinux.c
@@ -2201,7 +2201,7 @@ virSecuritySELinuxSetHostdevSubsysLabel(virSecurityManager *mgr,
if (!pci)
return -1;
- if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
+ if (pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
g_autofree char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev)
@@ -2437,7 +2437,7 @@ virSecuritySELinuxRestoreHostdevSubsysLabel(virSecurityManager
*mgr,
if (!pci)
return -1;
- if (pcisrc->backend == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
+ if (pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO) {
g_autofree char *vfioGroupDev = virPCIDeviceGetIOMMUGroupDev(pci);
if (!vfioGroupDev)
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c
index ac4225a783..dab181de47 100644
--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -1093,7 +1093,7 @@ get_files(vahControl * ctl)
virPCIDevice *pci =
virPCIDeviceNew(&dev->source.subsys.u.pci.addr);
virDeviceHostdevPCIDriverType driverType
- = dev->source.subsys.u.pci.backend;
+ = dev->source.subsys.u.pci.driver.type;
if (driverType == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO ||
driverType == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
diff --git a/tests/virhostdevtest.c b/tests/virhostdevtest.c
index d9ff992e91..e375fb2833 100644
--- a/tests/virhostdevtest.c
+++ b/tests/virhostdevtest.c
@@ -134,7 +134,7 @@ myInit(void)
subsys->u.pci.addr.bus = 0;
subsys->u.pci.addr.slot = i + 1;
subsys->u.pci.addr.function = 0;
- subsys->u.pci.backend = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
+ subsys->u.pci.driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
}
for (i = 0; i < nhostdevs; i++) {
--
2.41.0
8:53 a.m.
New subject: [libvirt PATCH v2 05/15] conf: put hostdev PCI backend into a
struct
On Mon, Nov 06, 2023 at 02:38:50 -0500, Laine Stump wrote:
The new struct is virDeviceHostdevPCIDriverInfo, and the
"backend"
enum in the hostdevDef will be replaced with a
virDeviceHostdevPCIDriverInfo named "driver'. Since the enum value in
this new struct is called "type", it means that all references to
"backend" will become "driver.type".
This will allow easily adding other items for new attributes in the
<driver> element / C struct, which will be useful once we are using
this new struct in multiple places.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
[...]
I will not repeat the comment about unneeded linebreaks.
@@ -29973,14 +29973,10 @@
virDomainNetDefActualToNetworkPort(virDomainDef *dom,
break;
case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN:
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("Unexpected PCI backend 'xen'"));
- break;
-
Falling through to virReportEnumRangeError from such cases isn't
something we normally do as virReportEnumRangeError is usually meant for
cases when the value is unknown.
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
8:28 p.m.
New subject: [libvirt PATCH v2 05/15] conf: put hostdev PCI backend into a
struct
On 11/27/23 9:53 AM, Peter Krempa wrote:
> @@ -29973,14 +29973,10 @@
virDomainNetDefActualToNetworkPort(virDomainDef *dom,
> break;
>
> case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN:
> - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> - _("Unexpected PCI backend 'xen'"));
> - break;
> -
Falling through to virReportEnumRangeError from such cases isn't
something we normally do as virReportEnumRangeError is usually meant for
cases when the value is unknown.
(Finally going through all of these)
the ..._XEN value does exist in the enum for the value in the NetDef
object, but there's no equivalent for it in the
virNetworkForwardDriverNameType enum that's used on the NetworkPort
object being converted *to*, so this actually *is* a range error
(although you're correct that it's not the normal case of a completely
unknown value).
So I would take the time to make a separate case / error message for
this particular value, however the patch immediately after this patch
completely removes all this code anyway (it switches to using the same
enum for both objects), so I'm just leaving it as it is.
2:51 a.m.
New subject: [libvirt PATCH v2 05/15] conf: put hostdev PCI backend into a
struct
On Sun, Dec 17, 2023 at 21:28:46 -0500, Laine Stump wrote:
On 11/27/23 9:53 AM, Peter Krempa wrote:
> > @@ -29973,14 +29973,10 @@ virDomainNetDefActualToNetworkPort(virDomainDef
*dom,
> > break;
> > case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN:
> > - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> > - _("Unexpected PCI backend
'xen'"));
> > - break;
> > -
>
> Falling through to virReportEnumRangeError from such cases isn't
> something we normally do as virReportEnumRangeError is usually meant for
> cases when the value is unknown.
(Finally going through all of these)
the ..._XEN value does exist in the enum for the value in the NetDef object,
but there's no equivalent for it in the virNetworkForwardDriverNameType enum
that's used on the NetworkPort object being converted *to*, so this actually
*is* a range error (although you're correct that it's not the normal case of
a completely unknown value).
The virReportEnumRangeError error reporting macro is in all other cases
used to report values out of range of the enum, the 'switch' statement
uses as an argument. Whatever it's then doing with the value is IMO out
of scope as it is in range of the enum being tested for values.
If it doesn't have any mapping where it is being converted *to*, it's
either an UNSUPORTED_CONFIG or INTERNAL_ERROR, but clearly the value is
in range of the source enum.
So I would take the time to make a separate case / error message for
this
particular value, however the patch immediately after this patch completely
removes all this code anyway (it switches to using the same enum for both
objects), so I'm just leaving it as it is.
Fair enough in this case, I just don't want to keep wrong examples in
the repo, so if you remove it it's okay. I was just reviewing these
chronologically.
1:38 a.m.
New subject: [libvirt PATCH v2 06/15] conf: use virDeviceHostdevPCIDriverInfo in network and networkport objects
The next step in consolidating parsing/formatting of the <driver>
element of these objects using a common struct and common code. This
eliminates the virNetworkForwardDriverNameType enum which is nearly
identical to virDeviceHostdevPCIDriverType (the only non-identical bit
was just because they'd gotten out of sync over time) and replaces its
uses with a virDeviceHostdevPCIDriverInfo (which is a struct that
contains a virDeviceHostdevPCIDriverType).
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/domain_conf.c | 48 +++---------------------------------
src/conf/network_conf.c | 21 ++++++----------
src/conf/network_conf.h | 17 ++-----------
src/conf/virnetworkportdef.c | 10 ++++----
src/conf/virnetworkportdef.h | 4 ++-
src/network/bridge_driver.c | 2 +-
6 files changed, 22 insertions(+), 80 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e322f1ffa7..82c1287986 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -29836,29 +29836,8 @@ virDomainNetDefActualFromNetworkPort(virDomainNetDef *iface,
}
actual->data.hostdev.def.source.subsys.type =
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI;
actual->data.hostdev.def.source.subsys.u.pci.addr =
port->plug.hostdevpci.addr;
- switch ((virNetworkForwardDriverNameType)port->plug.hostdevpci.driver) {
- case VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT:
- actual->data.hostdev.def.source.subsys.u.pci.driver.type =
- VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT;
- break;
-
- case VIR_NETWORK_FORWARD_DRIVER_NAME_KVM:
- actual->data.hostdev.def.source.subsys.u.pci.driver.type =
- VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM;
- break;
-
- case VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO:
- actual->data.hostdev.def.source.subsys.u.pci.driver.type =
- VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
- break;
-
- case VIR_NETWORK_FORWARD_DRIVER_NAME_LAST:
- default:
- virReportEnumRangeError(virNetworkForwardDriverNameType,
- port->plug.hostdevpci.driver);
- goto error;
- }
-
+ actual->data.hostdev.def.source.subsys.u.pci.driver.type
+ = port->plug.hostdevpci.driver.type;
break;
case VIR_NETWORK_PORT_PLUG_TYPE_LAST:
@@ -29959,27 +29938,8 @@ virDomainNetDefActualToNetworkPort(virDomainDef *dom,
}
port->plug.hostdevpci.managed =
virTristateBoolFromBool(actual->data.hostdev.def.managed);
port->plug.hostdevpci.addr =
actual->data.hostdev.def.source.subsys.u.pci.addr;
- switch (actual->data.hostdev.def.source.subsys.u.pci.driver.type) {
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT:
- port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT;
- break;
-
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM:
- port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_KVM;
- break;
-
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO:
- port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO;
- break;
-
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN:
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST:
- default:
- virReportEnumRangeError(virDeviceHostdevPCIDriverType,
-
actual->data.hostdev.def.source.subsys.u.pci.driver.type);
- return NULL;
- }
-
+ port->plug.hostdevpci.driver.type
+ = actual->data.hostdev.def.source.subsys.u.pci.driver.type;
break;
case VIR_DOMAIN_NET_TYPE_CLIENT:
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index b9601cb307..e3ad4c7340 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -56,13 +56,6 @@ VIR_ENUM_IMPL(virNetworkForwardHostdevDevice,
"none", "pci", "netdev",
);
-VIR_ENUM_IMPL(virNetworkForwardDriverName,
- VIR_NETWORK_FORWARD_DRIVER_NAME_LAST,
- "default",
- "kvm",
- "vfio",
-);
-
VIR_ENUM_IMPL(virNetworkTaint,
VIR_NETWORK_TAINT_LAST,
"hook-script",
@@ -1358,9 +1351,9 @@ virNetworkForwardDefParseXML(const char *networkName,
if ((driverNode = virXPathNode("./driver", ctxt))) {
if (virXMLPropEnum(driverNode, "name",
- virNetworkForwardDriverNameTypeFromString,
+ virDeviceHostdevPCIDriverTypeFromString,
VIR_XML_PROP_NONZERO,
- &def->driverName) < 0) {
+ &def->driver.type) < 0) {
return -1;
}
}
@@ -2351,19 +2344,19 @@ virNetworkDefFormatBuf(virBuffer *buf,
|| VIR_SOCKET_ADDR_VALID(&def->forward.addr.end)
|| def->forward.port.start
|| def->forward.port.end
- || (def->forward.driverName
- != VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT)
+ || (def->forward.driver.type
+ != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
|| def->forward.natIPv6);
virBufferAsprintf(buf, "%s>\n", shortforward ? "/" :
"");
virBufferAdjustIndent(buf, 2);
- if (def->forward.driverName) {
+ if (def->forward.driver.type) {
const char *driverName
- = virNetworkForwardDriverNameTypeToString(def->forward.driverName);
+ = virDeviceHostdevPCIDriverTypeToString(def->forward.driver.type);
if (!driverName) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("unexpected hostdev driver name type %1$d "),
- def->forward.driverName);
+ def->forward.driver.type);
return -1;
}
virBufferAsprintf(&driverAttrBuf, " name='%s'",
driverName);
diff --git a/src/conf/network_conf.h b/src/conf/network_conf.h
index 497ae765f2..1d7fd3ab6a 100644
--- a/src/conf/network_conf.h
+++ b/src/conf/network_conf.h
@@ -24,6 +24,7 @@
#define DNS_RECORD_LENGTH_SRV (512 - 30) /* Limit minus overhead as mentioned in
RFC-2782 */
#include "internal.h"
+#include "virconftypes.h"
#include "virsocketaddr.h"
#include "virnetdevbandwidth.h"
#include "virnetdevvportprofile.h"
@@ -88,20 +89,6 @@ typedef enum {
VIR_ENUM_DECL(virNetworkDHCPLeaseTimeUnit);
-/* The backend driver used for devices from the pool. Currently used
- * only for PCI devices (vfio vs. kvm), but could be used for other
- * device types in the future.
- */
-typedef enum {
- VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT, /* kvm now, could change */
- VIR_NETWORK_FORWARD_DRIVER_NAME_KVM, /* force legacy kvm style */
- VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO, /* force vfio */
-
- VIR_NETWORK_FORWARD_DRIVER_NAME_LAST
-} virNetworkForwardDriverNameType;
-
-VIR_ENUM_DECL(virNetworkForwardDriverName);
-
typedef struct _virNetworkDHCPLeaseTimeDef virNetworkDHCPLeaseTimeDef;
struct _virNetworkDHCPLeaseTimeDef {
unsigned long long expiry;
@@ -216,7 +203,7 @@ typedef struct _virNetworkForwardDef virNetworkForwardDef;
struct _virNetworkForwardDef {
int type; /* One of virNetworkForwardType constants */
bool managed; /* managed attribute for hostdev mode */
- virNetworkForwardDriverNameType driverName;
+ virDeviceHostdevPCIDriverInfo driver;
/* If there are multiple forward devices (i.e. a pool of
* interfaces), they will be listed here.
diff --git a/src/conf/virnetworkportdef.c b/src/conf/virnetworkportdef.c
index 402c0051ec..77ef705e18 100644
--- a/src/conf/virnetworkportdef.c
+++ b/src/conf/virnetworkportdef.c
@@ -226,9 +226,9 @@ virNetworkPortDefParseXML(xmlXPathContextPtr ctxt)
if ((driverNode = virXPathNode("./plug/driver", ctxt))) {
if (virXMLPropEnum(driverNode, "name",
- virNetworkForwardDriverNameTypeFromString,
+ virDeviceHostdevPCIDriverTypeFromString,
VIR_XML_PROP_NONZERO,
- &def->plug.hostdevpci.driver) < 0) {
+ &def->plug.hostdevpci.driver.type) < 0) {
return NULL;
}
}
@@ -356,10 +356,10 @@ virNetworkPortDefFormatBuf(virBuffer *buf,
virBufferAddLit(buf, ">\n");
virBufferAdjustIndent(buf, 2);
- if (def->plug.hostdevpci.driver) {
+ if (def->plug.hostdevpci.driver.type) {
virBufferEscapeString(&driverAttrBuf, "
name='%s'",
- virNetworkForwardDriverNameTypeToString(
- def->plug.hostdevpci.driver));
+ virDeviceHostdevPCIDriverTypeToString(
+ def->plug.hostdevpci.driver.type));
}
virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
diff --git a/src/conf/virnetworkportdef.h b/src/conf/virnetworkportdef.h
index bfe1dae9ea..9e51ab1a8b 100644
--- a/src/conf/virnetworkportdef.h
+++ b/src/conf/virnetworkportdef.h
@@ -22,6 +22,8 @@
#pragma once
#include "internal.h"
+#include "virconftypes.h"
+#include "device_conf.h"
#include "virnetdevvlan.h"
#include "virnetdevvportprofile.h"
#include "virnetdevbandwidth.h"
@@ -69,7 +71,7 @@ struct _virNetworkPortDef {
} direct;
struct {
virPCIDeviceAddress addr; /* PCI Address of device */
- unsigned int driver; /* virNetworkForwardDriverNameType */
+ virDeviceHostdevPCIDriverInfo driver;
virTristateBool managed;
} hostdevpci;
} plug;
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 4be740de2c..a9188c2436 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -3930,7 +3930,7 @@ networkAllocatePort(virNetworkObj *obj,
return -1;
}
port->plug.hostdevpci.addr = dev->device.pci;
- port->plug.hostdevpci.driver = netdef->forward.driverName;
+ port->plug.hostdevpci.driver.type = netdef->forward.driver.type;
port->plug.hostdevpci.managed =
virTristateBoolFromBool(netdef->forward.managed);
if (port->virtPortProfile) {
--
2.41.0
8:56 a.m.
New subject: [libvirt PATCH v2 06/15] conf: use virDeviceHostdevPCIDriverInfo
in network and networkport objects
On Mon, Nov 06, 2023 at 02:38:51 -0500, Laine Stump wrote:
The next step in consolidating parsing/formatting of the
<driver>
element of these objects using a common struct and common code. This
eliminates the virNetworkForwardDriverNameType enum which is nearly
identical to virDeviceHostdevPCIDriverType (the only non-identical bit
was just because they'd gotten out of sync over time) and replaces its
uses with a virDeviceHostdevPCIDriverInfo (which is a struct that
contains a virDeviceHostdevPCIDriverType).
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/domain_conf.c | 48 +++---------------------------------
src/conf/network_conf.c | 21 ++++++----------
src/conf/network_conf.h | 17 ++-----------
src/conf/virnetworkportdef.c | 10 ++++----
src/conf/virnetworkportdef.h | 4 ++-
src/network/bridge_driver.c | 2 +-
6 files changed, 22 insertions(+), 80 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e322f1ffa7..82c1287986 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -29836,29 +29836,8 @@ virDomainNetDefActualFromNetworkPort(virDomainNetDef *iface,
}
actual->data.hostdev.def.source.subsys.type =
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI;
actual->data.hostdev.def.source.subsys.u.pci.addr =
port->plug.hostdevpci.addr;
- switch ((virNetworkForwardDriverNameType)port->plug.hostdevpci.driver) {
- case VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT:
- actual->data.hostdev.def.source.subsys.u.pci.driver.type =
- VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT;
- break;
-
- case VIR_NETWORK_FORWARD_DRIVER_NAME_KVM:
- actual->data.hostdev.def.source.subsys.u.pci.driver.type =
- VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM;
- break;
-
- case VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO:
- actual->data.hostdev.def.source.subsys.u.pci.driver.type =
- VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
- break;
-
- case VIR_NETWORK_FORWARD_DRIVER_NAME_LAST:
- default:
- virReportEnumRangeError(virNetworkForwardDriverNameType,
- port->plug.hostdevpci.driver);
- goto error;
- }
-
+ actual->data.hostdev.def.source.subsys.u.pci.driver.type
+ = port->plug.hostdevpci.driver.type;
break;
case VIR_NETWORK_PORT_PLUG_TYPE_LAST:
@@ -29959,27 +29938,8 @@ virDomainNetDefActualToNetworkPort(virDomainDef *dom,
}
port->plug.hostdevpci.managed =
virTristateBoolFromBool(actual->data.hostdev.def.managed);
port->plug.hostdevpci.addr =
actual->data.hostdev.def.source.subsys.u.pci.addr;
- switch (actual->data.hostdev.def.source.subsys.u.pci.driver.type) {
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT:
- port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT;
- break;
-
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM:
- port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_KVM;
- break;
-
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO:
- port->plug.hostdevpci.driver = VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO;
- break;
-
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN:
- case VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_LAST:
- default:
- virReportEnumRangeError(virDeviceHostdevPCIDriverType,
-
actual->data.hostdev.def.source.subsys.u.pci.driver.type);
- return NULL;
- }
-
+ port->plug.hostdevpci.driver.type
+ = actual->data.hostdev.def.source.subsys.u.pci.driver.type;
It's okay if you un-break the line here. Don't need to create conflicts
in previous patches.
break;
case VIR_DOMAIN_NET_TYPE_CLIENT:
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index b9601cb307..e3ad4c7340 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -56,13 +56,6 @@ VIR_ENUM_IMPL(virNetworkForwardHostdevDevice,
"none", "pci", "netdev",
);
-VIR_ENUM_IMPL(virNetworkForwardDriverName,
- VIR_NETWORK_FORWARD_DRIVER_NAME_LAST,
- "default",
- "kvm",
- "vfio",
-);
-
VIR_ENUM_IMPL(virNetworkTaint,
VIR_NETWORK_TAINT_LAST,
"hook-script",
@@ -1358,9 +1351,9 @@ virNetworkForwardDefParseXML(const char *networkName,
if ((driverNode = virXPathNode("./driver", ctxt))) {
if (virXMLPropEnum(driverNode, "name",
- virNetworkForwardDriverNameTypeFromString,
+ virDeviceHostdevPCIDriverTypeFromString,
VIR_XML_PROP_NONZERO,
- &def->driverName) < 0) {
+ &def->driver.type) < 0) {
return -1;
}
}
@@ -2351,19 +2344,19 @@ virNetworkDefFormatBuf(virBuffer *buf,
|| VIR_SOCKET_ADDR_VALID(&def->forward.addr.end)
|| def->forward.port.start
|| def->forward.port.end
- || (def->forward.driverName
- != VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT)
+ || (def->forward.driver.type
+ != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
|| def->forward.natIPv6);
virBufferAsprintf(buf, "%s>\n", shortforward ? "/" :
"");
virBufferAdjustIndent(buf, 2);
- if (def->forward.driverName) {
+ if (def->forward.driver.type) {
const char *driverName
- = virNetworkForwardDriverNameTypeToString(def->forward.driverName);
+ = virDeviceHostdevPCIDriverTypeToString(def->forward.driver.type);
if (!driverName) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("unexpected hostdev driver name type %1$d
"),
- def->forward.driverName);
+ def->forward.driver.type);
return -1;
}
virBufferAsprintf(&driverAttrBuf, " name='%s'",
driverName);
diff --git a/src/conf/network_conf.h b/src/conf/network_conf.h
index 497ae765f2..1d7fd3ab6a 100644
--- a/src/conf/network_conf.h
+++ b/src/conf/network_conf.h
@@ -24,6 +24,7 @@
#define DNS_RECORD_LENGTH_SRV (512 - 30) /* Limit minus overhead as mentioned in
RFC-2782 */
#include "internal.h"
+#include "virconftypes.h"
#include "virsocketaddr.h"
#include "virnetdevbandwidth.h"
#include "virnetdevvportprofile.h"
@@ -88,20 +89,6 @@ typedef enum {
VIR_ENUM_DECL(virNetworkDHCPLeaseTimeUnit);
-/* The backend driver used for devices from the pool. Currently used
- * only for PCI devices (vfio vs. kvm), but could be used for other
- * device types in the future.
- */
-typedef enum {
- VIR_NETWORK_FORWARD_DRIVER_NAME_DEFAULT, /* kvm now, could change */
- VIR_NETWORK_FORWARD_DRIVER_NAME_KVM, /* force legacy kvm style */
- VIR_NETWORK_FORWARD_DRIVER_NAME_VFIO, /* force vfio */
-
- VIR_NETWORK_FORWARD_DRIVER_NAME_LAST
-} virNetworkForwardDriverNameType;
-
-VIR_ENUM_DECL(virNetworkForwardDriverName);
-
typedef struct _virNetworkDHCPLeaseTimeDef virNetworkDHCPLeaseTimeDef;
struct _virNetworkDHCPLeaseTimeDef {
unsigned long long expiry;
@@ -216,7 +203,7 @@ typedef struct _virNetworkForwardDef virNetworkForwardDef;
struct _virNetworkForwardDef {
int type; /* One of virNetworkForwardType constants */
bool managed; /* managed attribute for hostdev mode */
- virNetworkForwardDriverNameType driverName;
+ virDeviceHostdevPCIDriverInfo driver;
/* If there are multiple forward devices (i.e. a pool of
* interfaces), they will be listed here.
diff --git a/src/conf/virnetworkportdef.c b/src/conf/virnetworkportdef.c
index 402c0051ec..77ef705e18 100644
--- a/src/conf/virnetworkportdef.c
+++ b/src/conf/virnetworkportdef.c
@@ -226,9 +226,9 @@ virNetworkPortDefParseXML(xmlXPathContextPtr ctxt)
if ((driverNode = virXPathNode("./plug/driver", ctxt))) {
if (virXMLPropEnum(driverNode, "name",
- virNetworkForwardDriverNameTypeFromString,
+ virDeviceHostdevPCIDriverTypeFromString,
VIR_XML_PROP_NONZERO,
- &def->plug.hostdevpci.driver) < 0) {
+ &def->plug.hostdevpci.driver.type) < 0) {
return NULL;
}
}
@@ -356,10 +356,10 @@ virNetworkPortDefFormatBuf(virBuffer *buf,
virBufferAddLit(buf, ">\n");
virBufferAdjustIndent(buf, 2);
- if (def->plug.hostdevpci.driver) {
+ if (def->plug.hostdevpci.driver.type) {
virBufferEscapeString(&driverAttrBuf, "
name='%s'",
- virNetworkForwardDriverNameTypeToString(
- def->plug.hostdevpci.driver));
+ virDeviceHostdevPCIDriverTypeToString(
+ def->plug.hostdevpci.driver.type));
}
virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
diff --git a/src/conf/virnetworkportdef.h b/src/conf/virnetworkportdef.h
index bfe1dae9ea..9e51ab1a8b 100644
--- a/src/conf/virnetworkportdef.h
+++ b/src/conf/virnetworkportdef.h
@@ -22,6 +22,8 @@
#pragma once
#include "internal.h"
+#include "virconftypes.h"
+#include "device_conf.h"
#include "virnetdevvlan.h"
#include "virnetdevvportprofile.h"
#include "virnetdevbandwidth.h"
@@ -69,7 +71,7 @@ struct _virNetworkPortDef {
} direct;
struct {
virPCIDeviceAddress addr; /* PCI Address of device */
- unsigned int driver; /* virNetworkForwardDriverNameType */
+ virDeviceHostdevPCIDriverInfo driver;
You can ignore my earlier comment about this.
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
1:38 a.m.
New subject: [libvirt PATCH v2 07/15] conf: split out hostdev <driver> parse/format to their own functions
This is done so that we can re-use the same parser/formatter for
<network> and <networkport>
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/device_conf.c | 41 +++++++++++++++++++++++++++++++++++++++++
src/conf/device_conf.h | 7 +++++++
src/conf/domain_conf.c | 28 +++++-----------------------
3 files changed, 53 insertions(+), 23 deletions(-)
diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
index 25a522671e..e022783816 100644
--- a/src/conf/device_conf.c
+++ b/src/conf/device_conf.c
@@ -55,6 +55,47 @@ VIR_ENUM_IMPL(virDomainDeviceAddress,
"unassigned",
);
+
+int
+virDeviceHostdevPCIDriverInfoParseXML(xmlNodePtr node,
+ virDeviceHostdevPCIDriverInfo *driver)
+{
+ if (virXMLPropEnum(node, "name",
+ virDeviceHostdevPCIDriverTypeFromString,
+ VIR_XML_PROP_NONZERO,
+ &driver->type) < 0) {
+ return -1;
+ }
+
+ return 0;
+}
+
+
+int
+virDeviceHostdevPCIDriverInfoFormat(virBuffer *buf,
+ const virDeviceHostdevPCIDriverInfo *driver)
+{
+ g_auto(virBuffer) driverAttrBuf = VIR_BUFFER_INITIALIZER;
+
+ if (driver->type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
+ const char *driverType
+ = virDeviceHostdevPCIDriverTypeToString(driver->type);
+
+ if (!driverType) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("unexpected pci hostdev driver type %1$d"),
+ driver->type);
+ return -1;
+ }
+
+ virBufferAsprintf(&driverAttrBuf, " name='%s'",
driverType);
+ }
+
+ virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
+ return 0;
+}
+
+
static int
virZPCIDeviceAddressParseXML(xmlNodePtr node,
virPCIDeviceAddress *addr)
diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index 3a7a6c3f99..9f4b9f5375 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -25,6 +25,7 @@
#include <libxml/xpath.h>
#include "internal.h"
+#include "virconftypes.h"
#include "virbuffer.h"
#include "virccw.h"
#include "virpci.h"
@@ -185,6 +186,12 @@ struct _virDomainDeviceInfo {
bool isolationGroupLocked;
};
+int virDeviceHostdevPCIDriverInfoParseXML(xmlNodePtr node,
+ virDeviceHostdevPCIDriverInfo *driver);
+
+int virDeviceHostdevPCIDriverInfoFormat(virBuffer *buf,
+ const virDeviceHostdevPCIDriverInfo *driver);
+
void virDomainDeviceInfoClear(virDomainDeviceInfo *info);
void virDomainDeviceInfoFree(virDomainDeviceInfo *info);
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 82c1287986..d87ead291c 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -6267,13 +6267,9 @@ virDomainHostdevDefParseXMLSubsys(xmlNodePtr node,
if (virDomainHostdevSubsysPCIDefParseXML(sourcenode, ctxt, def, flags) < 0)
return -1;
- if ((driver_node = virXPathNode("./driver", ctxt))) {
- if (virXMLPropEnum(driver_node, "name",
- virDeviceHostdevPCIDriverTypeFromString,
- VIR_XML_PROP_NONZERO,
- &pcisrc->driver.type) < 0) {
- return -1;
- }
+ if ((driver_node = virXPathNode("./driver", ctxt)) &&
+ virDeviceHostdevPCIDriverInfoParseXML(driver_node, &pcisrc->driver)
< 0) {
+ return -1;
}
break;
@@ -23328,26 +23324,12 @@ virDomainHostdevDefFormatSubsysPCI(virBuffer *buf,
unsigned int flags,
bool includeTypeInAddr)
{
- g_auto(virBuffer) driverAttrBuf = VIR_BUFFER_INITIALIZER;
g_auto(virBuffer) sourceAttrBuf = VIR_BUFFER_INITIALIZER;
g_auto(virBuffer) sourceChildBuf = VIR_BUFFER_INIT_CHILD(buf);
virDomainHostdevSubsysPCI *pcisrc = &def->source.subsys.u.pci;
- if (pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
- const char *driverType
- = virDeviceHostdevPCIDriverTypeToString(pcisrc->driver.type);
-
- if (!driverType) {
- virReportError(VIR_ERR_INTERNAL_ERROR,
- _("unexpected pci hostdev driver type %1$d"),
- pcisrc->driver.type);
- return -1;
- }
-
- virBufferAsprintf(&driverAttrBuf, " name='%s'",
driverType);
- }
-
- virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
+ if (virDeviceHostdevPCIDriverInfoFormat(buf, &pcisrc->driver) < 0)
+ return -1;
if (def->writeFiltering != VIR_TRISTATE_BOOL_ABSENT)
virBufferAsprintf(&sourceAttrBuf, "
writeFiltering='%s'",
--
2.41.0
8:58 a.m.
New subject: [libvirt PATCH v2 07/15] conf: split out hostdev <driver>
parse/format to their own functions
On Mon, Nov 06, 2023 at 02:38:52 -0500, Laine Stump wrote:
This is done so that we can re-use the same parser/formatter for
<network> and <networkport>
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/device_conf.c | 41 +++++++++++++++++++++++++++++++++++++++++
src/conf/device_conf.h | 7 +++++++
src/conf/domain_conf.c | 28 +++++-----------------------
3 files changed, 53 insertions(+), 23 deletions(-)
diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
index 25a522671e..e022783816 100644
--- a/src/conf/device_conf.c
+++ b/src/conf/device_conf.c
@@ -55,6 +55,47 @@ VIR_ENUM_IMPL(virDomainDeviceAddress,
"unassigned",
);
[...]
+int
+virDeviceHostdevPCIDriverInfoFormat(virBuffer *buf,
+ const virDeviceHostdevPCIDriverInfo *driver)
+{
+ g_auto(virBuffer) driverAttrBuf = VIR_BUFFER_INITIALIZER;
+
+ if (driver->type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
+ const char *driverType
+ = virDeviceHostdevPCIDriverTypeToString(driver->type);
-||-
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
1:38 a.m.
New subject: [libvirt PATCH v2 08/15] conf: use new common parser/formatter for hostdev driver in network XML
Now if a new attribute is added to <driver>, we only need to update
the formatting/parsing in one place.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/network_conf.c | 24 ++++--------------------
src/conf/virnetworkportdef.c | 21 ++++++---------------
2 files changed, 10 insertions(+), 35 deletions(-)
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index e3ad4c7340..2d78d588aa 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -1349,13 +1349,9 @@ virNetworkForwardDefParseXML(const char *networkName,
def->managed = true;
}
- if ((driverNode = virXPathNode("./driver", ctxt))) {
- if (virXMLPropEnum(driverNode, "name",
- virDeviceHostdevPCIDriverTypeFromString,
- VIR_XML_PROP_NONZERO,
- &def->driver.type) < 0) {
+ if ((driverNode = virXPathNode("./driver", ctxt)) &&
+ virDeviceHostdevPCIDriverInfoParseXML(driverNode, &def->driver) < 0) {
return -1;
- }
}
/* bridge and hostdev modes can use a pool of physical interfaces */
@@ -2319,7 +2315,6 @@ virNetworkDefFormatBuf(virBuffer *buf,
if (def->forward.type != VIR_NETWORK_FORWARD_NONE) {
const char *dev = NULL;
const char *mode = virNetworkForwardTypeToString(def->forward.type);
- g_auto(virBuffer) driverAttrBuf = VIR_BUFFER_INITIALIZER;
if (!def->forward.npfs)
dev = virNetworkDefForwardIf(def, 0);
@@ -2350,19 +2345,8 @@ virNetworkDefFormatBuf(virBuffer *buf,
virBufferAsprintf(buf, "%s>\n", shortforward ? "/" :
"");
virBufferAdjustIndent(buf, 2);
- if (def->forward.driver.type) {
- const char *driverName
- = virDeviceHostdevPCIDriverTypeToString(def->forward.driver.type);
- if (!driverName) {
- virReportError(VIR_ERR_INTERNAL_ERROR,
- _("unexpected hostdev driver name type %1$d "),
- def->forward.driver.type);
- return -1;
- }
- virBufferAsprintf(&driverAttrBuf, " name='%s'",
driverName);
- }
-
- virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
+ if (virDeviceHostdevPCIDriverInfoFormat(buf, &def->forward.driver) < 0)
+ return -1;
if (def->forward.type == VIR_NETWORK_FORWARD_NAT) {
if (virNetworkForwardNatDefFormat(buf, &def->forward) < 0)
diff --git a/src/conf/virnetworkportdef.c b/src/conf/virnetworkportdef.c
index 77ef705e18..49d00b2ea6 100644
--- a/src/conf/virnetworkportdef.c
+++ b/src/conf/virnetworkportdef.c
@@ -224,13 +224,10 @@ virNetworkPortDefParseXML(xmlXPathContextPtr ctxt)
&def->plug.hostdevpci.managed) < 0)
return NULL;
- if ((driverNode = virXPathNode("./plug/driver", ctxt))) {
- if (virXMLPropEnum(driverNode, "name",
- virDeviceHostdevPCIDriverTypeFromString,
- VIR_XML_PROP_NONZERO,
- &def->plug.hostdevpci.driver.type) < 0) {
- return NULL;
- }
+ if ((driverNode = virXPathNode("./plug/driver", ctxt)) &&
+ virDeviceHostdevPCIDriverInfoParseXML(driverNode,
+ &def->plug.hostdevpci.driver)
< 0) {
+ return NULL;
}
if (!(addressNode = virXPathNode("./plug/address", ctxt))) {
@@ -321,7 +318,6 @@ virNetworkPortDefFormatBuf(virBuffer *buf,
virTristateBoolTypeToString(def->trustGuestRxFilters));
if (def->plugtype != VIR_NETWORK_PORT_PLUG_TYPE_NONE) {
- g_auto(virBuffer) driverAttrBuf = VIR_BUFFER_INITIALIZER;
virBufferAsprintf(buf, "<plug type='%s'",
virNetworkPortPlugTypeToString(def->plugtype));
@@ -356,13 +352,8 @@ virNetworkPortDefFormatBuf(virBuffer *buf,
virBufferAddLit(buf, ">\n");
virBufferAdjustIndent(buf, 2);
- if (def->plug.hostdevpci.driver.type) {
- virBufferEscapeString(&driverAttrBuf, "
name='%s'",
- virDeviceHostdevPCIDriverTypeToString(
- def->plug.hostdevpci.driver.type));
- }
-
- virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
+ if (virDeviceHostdevPCIDriverInfoFormat(buf,
&def->plug.hostdevpci.driver) < 0)
+ return -1;
virPCIDeviceAddressFormat(buf, def->plug.hostdevpci.addr, false);
virBufferAdjustIndent(buf, -2);
--
2.41.0
8:59 a.m.
New subject: [libvirt PATCH v2 08/15] conf: use new common parser/formatter
for hostdev driver in network XML
On Mon, Nov 06, 2023 at 02:38:53 -0500, Laine Stump wrote:
Now if a new attribute is added to <driver>, we only need to
update
the formatting/parsing in one place.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/network_conf.c | 24 ++++--------------------
src/conf/virnetworkportdef.c | 21 ++++++---------------
2 files changed, 10 insertions(+), 35 deletions(-)
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
1:38 a.m.
New subject: [libvirt PATCH v2 09/15] tests: remove explicit <driver name='vfio'/> from hostdev test cases
The long-deprecated use of <driver name='vfio|xen|kvm'/> in domain xml
for <hostdev> devices was only ever necessary during the period when
libvirt (and the Linux kernel) supported both VFIO and "legacy KVM"
styles of hostdev device assignment for QEMU. This became pointless
many years ago when legacy KVM device assignment was removed from the
kernel, and support for that style of device assignment was completely
disabled in the libvirt source in 2019 (commit
v5.6.0-316-g2e7225ea8c).
Nevertheless, there were instances of <driver name='vfio'/> in the
unit test data that were then (unnecessarily) propagated to several
more tests over the years. This patch cleans out those unnecessary
explicit settings of driver name='vfio' in all QEMU unit test data,
proving that the attribute is no longer (externally) needed while also
making it simpler to properly test when a later patch "re-animates"
the driver name attribute for a slightly different (but related) use.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
tests/qemuxml2argvdata/hostdev-pci-address-unassigned.xml | 4 ----
tests/qemuxml2argvdata/hostdev-pci-multifunction.xml | 7 -------
tests/qemuxml2argvdata/hostdev-vfio-multidomain.xml | 1 -
.../hostdev-vfio-zpci-autogenerate-fids.xml | 2 --
.../hostdev-vfio-zpci-autogenerate-uids.xml | 2 --
tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml | 1 -
tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml | 2 --
.../qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.xml | 1 -
tests/qemuxml2argvdata/hostdev-vfio-zpci-duplicate.xml | 2 --
.../hostdev-vfio-zpci-invalid-uid-valid-fid.xml | 1 -
.../hostdev-vfio-zpci-multidomain-many.xml | 8 --------
tests/qemuxml2argvdata/hostdev-vfio-zpci-set-zero.xml | 1 -
tests/qemuxml2argvdata/hostdev-vfio-zpci-uid-set-zero.xml | 1 -
tests/qemuxml2argvdata/hostdev-vfio-zpci-wrong-arch.xml | 1 -
tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 1 -
tests/qemuxml2argvdata/hostdev-vfio.xml | 1 -
tests/qemuxml2argvdata/net-hostdev-vfio-multidomain.xml | 1 -
tests/qemuxml2argvdata/net-hostdev-vfio.xml | 1 -
tests/qemuxml2argvdata/pseries-hostdevs-1.xml | 3 ---
tests/qemuxml2argvdata/pseries-hostdevs-2.xml | 2 --
tests/qemuxml2argvdata/pseries-hostdevs-3.xml | 2 --
.../hostdev-pci-address-unassigned.x86_64-latest.xml | 4 ----
.../hostdev-pci-multifunction.x86_64-latest.xml | 7 -------
.../hostdev-vfio-zpci-autogenerate-fids.s390x-latest.xml | 2 --
.../hostdev-vfio-zpci-autogenerate-uids.s390x-latest.xml | 2 --
.../hostdev-vfio-zpci-autogenerate.s390x-latest.xml | 1 -
.../hostdev-vfio-zpci-boundaries.s390x-latest.xml | 2 --
.../hostdev-vfio-zpci-ccw-memballoon.s390x-latest.xml | 1 -
.../hostdev-vfio-zpci-multidomain-many.s390x-latest.xml | 8 --------
.../qemuxml2xmloutdata/hostdev-vfio-zpci.s390x-latest.xml | 1 -
tests/qemuxml2xmloutdata/hostdev-vfio.x86_64-latest.xml | 1 -
.../qemuxml2xmloutdata/net-hostdev-vfio.x86_64-latest.xml | 1 -
.../pseries-hostdevs-1.ppc64-latest.xml | 3 ---
.../pseries-hostdevs-2.ppc64-latest.xml | 2 --
.../pseries-hostdevs-3.ppc64-latest.xml | 2 --
35 files changed, 82 deletions(-)
diff --git a/tests/qemuxml2argvdata/hostdev-pci-address-unassigned.xml
b/tests/qemuxml2argvdata/hostdev-pci-address-unassigned.xml
index 9a2685ca0e..864ef303c0 100644
--- a/tests/qemuxml2argvdata/hostdev-pci-address-unassigned.xml
+++ b/tests/qemuxml2argvdata/hostdev-pci-address-unassigned.xml
@@ -14,26 +14,22 @@
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x0'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x1'/>
</source>
<address type='unassigned'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x2'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x3'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-pci-multifunction.xml
b/tests/qemuxml2argvdata/hostdev-pci-multifunction.xml
index 06c889c64d..ba0a593628 100644
--- a/tests/qemuxml2argvdata/hostdev-pci-multifunction.xml
+++ b/tests/qemuxml2argvdata/hostdev-pci-multifunction.xml
@@ -14,43 +14,36 @@
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x0'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x1'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x0'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x2'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x3'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x1'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x2'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-multidomain.xml
b/tests/qemuxml2argvdata/hostdev-vfio-multidomain.xml
index b720883913..7afe18b24e 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-multidomain.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-multidomain.xml
@@ -23,7 +23,6 @@
<controller type='ide' index='0'/>
<controller type='pci' index='0' model='pci-root'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0021' bus='222' slot='31'
function='1'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.xml
index 49c26e2434..e72c524a98 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-fids.xml
@@ -8,7 +8,6 @@
<devices>
<emulator>/usr/bin/qemu-system-s390x</emulator>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -17,7 +16,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.xml
index e74e0116c7..1ed75aae48 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate-uids.xml
@@ -8,7 +8,6 @@
<devices>
<emulator>/usr/bin/qemu-system-s390x</emulator>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -17,7 +16,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x01'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
index 36161006ab..b4b1ce315f 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
@@ -8,7 +8,6 @@
<devices>
<emulator>/usr/bin/qemu-system-s390x</emulator>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
index 1e6060345b..fe005af488 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
@@ -9,7 +9,6 @@
<emulator>/usr/bin/qemu-system-s390x</emulator>
<controller type='pci' index='0' model='pci-root'/>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0xffff' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -18,7 +17,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.xml
index ef5e97fc9c..bb6861f103 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-ccw-memballoon.xml
@@ -8,7 +8,6 @@
<devices>
<emulator>/usr/bin/qemu-system-s390x</emulator>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-duplicate.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-duplicate.xml
index 6062ae4940..53cf48ea6a 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-duplicate.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-duplicate.xml
@@ -9,7 +9,6 @@
<emulator>/usr/bin/qemu-system-s390x</emulator>
<controller type='pci' index='0' model='pci-root'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -18,7 +17,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-invalid-uid-valid-fid.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-invalid-uid-valid-fid.xml
index 6e7101489e..1026661730 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-invalid-uid-valid-fid.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-invalid-uid-valid-fid.xml
@@ -9,7 +9,6 @@
<emulator>/usr/bin/qemu-system-s390x</emulator>
<controller type='pci' index='0' model='pci-root'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
index da8305dd6d..36c11a8311 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
@@ -9,7 +9,6 @@
<emulator>/usr/bin/qemu-system-s390x</emulator>
<controller type='pci' index='0' model='pci-root'/>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -18,7 +17,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0002' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -27,20 +25,17 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0003' bus='0x00' slot='0x00'
function='0x0'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0004' bus='0x00' slot='0x00'
function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x05' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -49,7 +44,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0006' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -58,7 +52,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0007' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -67,7 +60,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0008' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-set-zero.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-set-zero.xml
index fd3d1193f1..eefe05de39 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-set-zero.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-set-zero.xml
@@ -9,7 +9,6 @@
<emulator>/usr/bin/qemu-system-s390x</emulator>
<controller type='pci' index='0' model='pci-root'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-uid-set-zero.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-uid-set-zero.xml
index 6bfbfe611b..fb0e680b55 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-uid-set-zero.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-uid-set-zero.xml
@@ -8,7 +8,6 @@
<devices>
<emulator>/usr/bin/qemu-system-s390x</emulator>
<hostdev mode='subsystem' type='pci'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci-wrong-arch.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci-wrong-arch.xml
index a9a5afd6dd..8b3cc45ddf 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci-wrong-arch.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci-wrong-arch.xml
@@ -21,7 +21,6 @@
</disk>
<controller type='pci' index='0' model='pci-root'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='00' slot='00'
function='0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
b/tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
index 002b99c52d..5f439eff73 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
@@ -9,7 +9,6 @@
<emulator>/usr/bin/qemu-system-s390x</emulator>
<controller type='pci' index='0' model='pci-root'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio.xml
b/tests/qemuxml2argvdata/hostdev-vfio.xml
index 1b438a2eef..a03870f6e0 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio.xml
@@ -25,7 +25,6 @@
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x1'/>
</source>
diff --git a/tests/qemuxml2argvdata/net-hostdev-vfio-multidomain.xml
b/tests/qemuxml2argvdata/net-hostdev-vfio-multidomain.xml
index ae8c4e7e80..cdadf4f2cb 100644
--- a/tests/qemuxml2argvdata/net-hostdev-vfio-multidomain.xml
+++ b/tests/qemuxml2argvdata/net-hostdev-vfio-multidomain.xml
@@ -24,7 +24,6 @@
<controller type='pci' index='0' model='pci-root'/>
<interface type='hostdev' managed='yes'>
<mac address='00:11:22:33:44:55'/>
- <driver name='vfio'/>
<source>
<address type='pci' domain='0x0021' bus='0xde'
slot='0x1f' function='0x1'/>
</source>
diff --git a/tests/qemuxml2argvdata/net-hostdev-vfio.xml
b/tests/qemuxml2argvdata/net-hostdev-vfio.xml
index e6e6b6e5d3..9cdb8a602d 100644
--- a/tests/qemuxml2argvdata/net-hostdev-vfio.xml
+++ b/tests/qemuxml2argvdata/net-hostdev-vfio.xml
@@ -24,7 +24,6 @@
<controller type='pci' index='0' model='pci-root'/>
<interface type='hostdev' managed='yes'>
<mac address='00:11:22:33:44:55'/>
- <driver name='vfio'/>
<source>
<address type='pci' domain='0x0000' bus='0x06'
slot='0x12' function='0x1'/>
</source>
diff --git a/tests/qemuxml2argvdata/pseries-hostdevs-1.xml
b/tests/qemuxml2argvdata/pseries-hostdevs-1.xml
index 04f3ec4759..5d09413a98 100644
--- a/tests/qemuxml2argvdata/pseries-hostdevs-1.xml
+++ b/tests/qemuxml2argvdata/pseries-hostdevs-1.xml
@@ -11,7 +11,6 @@
<!-- This hostdev will cause a new PHB to be created because its
isolation group is 1 (IOMMU group 0) -->
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x0'/>
</source>
@@ -19,7 +18,6 @@
<!-- This hostdev can't share the PHB that was just created, because
its isolation group is 2 (IOMMU group 1) -->
<interface type='hostdev' managed='yes'>
- <driver name='vfio'/>
<source>
<address type='pci' domain='0x0005' bus='0x90'
slot='0x01' function='0x0'/>
</source>
@@ -28,7 +26,6 @@
<!-- This hostdev will be placed on the first PHB, since its isolation
group is 1 (IOMMU group 0) just like the first hostdev -->
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x1'/>
</source>
diff --git a/tests/qemuxml2argvdata/pseries-hostdevs-2.xml
b/tests/qemuxml2argvdata/pseries-hostdevs-2.xml
index 6568475c72..00d4228499 100644
--- a/tests/qemuxml2argvdata/pseries-hostdevs-2.xml
+++ b/tests/qemuxml2argvdata/pseries-hostdevs-2.xml
@@ -17,7 +17,6 @@
despite being in the separate isolation group 1 (IOMMU group 0),
because the address has been requested explicitly by the user -->
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x0'/>
</source>
@@ -26,7 +25,6 @@
<!-- This hostdev can use neither the PHB that was just created, nor the
default one, because it's in isolation group 2 (IOMMU group 1) -->
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2argvdata/pseries-hostdevs-3.xml
b/tests/qemuxml2argvdata/pseries-hostdevs-3.xml
index 4f51f48c90..64ba95ca30 100644
--- a/tests/qemuxml2argvdata/pseries-hostdevs-3.xml
+++ b/tests/qemuxml2argvdata/pseries-hostdevs-3.xml
@@ -11,7 +11,6 @@
<!-- This hostdev will cause a new PHB to be created because its isolation
group is 1 (IOMMU group 0). It will be PHB 2 due to the address -->
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x0'/>
</source>
@@ -20,7 +19,6 @@
<!-- This hostdev will be placed on the same PHB, since its isolation
group is also 1 (IOMMU group 0) -->
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x1'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-pci-address-unassigned.x86_64-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-pci-address-unassigned.x86_64-latest.xml
index 480d2f8363..9da9a8a07e 100644
--- a/tests/qemuxml2xmloutdata/hostdev-pci-address-unassigned.x86_64-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-pci-address-unassigned.x86_64-latest.xml
@@ -28,28 +28,24 @@
<input type='keyboard' bus='ps2'/>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x02' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x1'/>
</source>
<address type='unassigned'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x2'/>
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x3'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-pci-multifunction.x86_64-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-pci-multifunction.x86_64-latest.xml
index a29a27e85b..9530c28e14 100644
--- a/tests/qemuxml2xmloutdata/hostdev-pci-multifunction.x86_64-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-pci-multifunction.x86_64-latest.xml
@@ -28,49 +28,42 @@
<input type='keyboard' bus='ps2'/>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x02' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x1'/>
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x04' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x2'/>
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x05' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x3'/>
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x06' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x1'/>
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x2'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate-fids.s390x-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate-fids.s390x-latest.xml
index dd1dea4e99..f23ad5b90c 100644
--- a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate-fids.s390x-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate-fids.s390x-latest.xml
@@ -20,7 +20,6 @@
<controller type='pci' index='0' model='pci-root'/>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -29,7 +28,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate-uids.s390x-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate-uids.s390x-latest.xml
index 1a52487692..9bf2ce32be 100644
--- a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate-uids.s390x-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate-uids.s390x-latest.xml
@@ -20,7 +20,6 @@
<controller type='pci' index='0' model='pci-root'/>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -29,7 +28,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x01'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.s390x-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.s390x-latest.xml
index 670f8c68b4..94f3c04b9a 100644
--- a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.s390x-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.s390x-latest.xml
@@ -20,7 +20,6 @@
<controller type='pci' index='0' model='pci-root'/>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.s390x-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.s390x-latest.xml
index df55f79501..8b0044af1c 100644
--- a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.s390x-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.s390x-latest.xml
@@ -25,7 +25,6 @@
</controller>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0xffff' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -34,7 +33,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-ccw-memballoon.s390x-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-ccw-memballoon.s390x-latest.xml
index 7df6491b68..e0ff360553 100644
--- a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-ccw-memballoon.s390x-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-ccw-memballoon.s390x-latest.xml
@@ -18,7 +18,6 @@
<controller type='pci' index='0' model='pci-root'/>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.s390x-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.s390x-latest.xml
index e64d7de561..70d592f2df 100644
--- a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.s390x-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.s390x-latest.xml
@@ -20,7 +20,6 @@
<controller type='pci' index='0' model='pci-root'/>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -29,7 +28,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0002' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -38,7 +36,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0003' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -47,7 +44,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0004' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -56,7 +52,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -65,7 +60,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0006' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -74,7 +68,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0007' bus='0x00' slot='0x00'
function='0x0'/>
</source>
@@ -83,7 +76,6 @@
</address>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0008' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci.s390x-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci.s390x-latest.xml
index 5e14a63810..c8a1407427 100644
--- a/tests/qemuxml2xmloutdata/hostdev-vfio-zpci.s390x-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio-zpci.s390x-latest.xml
@@ -20,7 +20,6 @@
<controller type='pci' index='0' model='pci-root'/>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio.x86_64-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-vfio.x86_64-latest.xml
index b660d245a1..3915b515f2 100644
--- a/tests/qemuxml2xmloutdata/hostdev-vfio.x86_64-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio.x86_64-latest.xml
@@ -34,7 +34,6 @@
<input type='keyboard' bus='ps2'/>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x1'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/net-hostdev-vfio.x86_64-latest.xml
b/tests/qemuxml2xmloutdata/net-hostdev-vfio.x86_64-latest.xml
index 167e1b1fea..1eee425593 100644
--- a/tests/qemuxml2xmloutdata/net-hostdev-vfio.x86_64-latest.xml
+++ b/tests/qemuxml2xmloutdata/net-hostdev-vfio.x86_64-latest.xml
@@ -32,7 +32,6 @@
<controller type='pci' index='0' model='pci-root'/>
<interface type='hostdev' managed='yes'>
<mac address='00:11:22:33:44:55'/>
- <driver name='vfio'/>
<source>
<address type='pci' domain='0x0000' bus='0x06'
slot='0x12' function='0x1'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/pseries-hostdevs-1.ppc64-latest.xml
b/tests/qemuxml2xmloutdata/pseries-hostdevs-1.ppc64-latest.xml
index db369a1fc7..d0ad114d34 100644
--- a/tests/qemuxml2xmloutdata/pseries-hostdevs-1.ppc64-latest.xml
+++ b/tests/qemuxml2xmloutdata/pseries-hostdevs-1.ppc64-latest.xml
@@ -32,7 +32,6 @@
</controller>
<interface type='hostdev' managed='yes'>
<mac address='52:54:00:6d:90:02'/>
- <driver name='vfio'/>
<source>
<address type='pci' domain='0x0005' bus='0x90'
slot='0x01' function='0x0'/>
</source>
@@ -40,14 +39,12 @@
</interface>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x02'
slot='0x01' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x1'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/pseries-hostdevs-2.ppc64-latest.xml
b/tests/qemuxml2xmloutdata/pseries-hostdevs-2.ppc64-latest.xml
index 09b657698d..4ffcae80b8 100644
--- a/tests/qemuxml2xmloutdata/pseries-hostdevs-2.ppc64-latest.xml
+++ b/tests/qemuxml2xmloutdata/pseries-hostdevs-2.ppc64-latest.xml
@@ -35,14 +35,12 @@
</controller>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x01'
slot='0x02' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x0'/>
</source>
diff --git a/tests/qemuxml2xmloutdata/pseries-hostdevs-3.ppc64-latest.xml
b/tests/qemuxml2xmloutdata/pseries-hostdevs-3.ppc64-latest.xml
index 58ffb09c3b..e06901a9a4 100644
--- a/tests/qemuxml2xmloutdata/pseries-hostdevs-3.ppc64-latest.xml
+++ b/tests/qemuxml2xmloutdata/pseries-hostdevs-3.ppc64-latest.xml
@@ -32,14 +32,12 @@
</controller>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x02'
slot='0x01' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x01' slot='0x00'
function='0x1'/>
</source>
--
2.41.0
9:03 a.m.
New subject: [libvirt PATCH v2 09/15] tests: remove explicit <driver
name='vfio'/> from hostdev test cases
On Mon, Nov 06, 2023 at 02:38:54 -0500, Laine Stump wrote:
The long-deprecated use of <driver
name='vfio|xen|kvm'/> in domain xml
for <hostdev> devices was only ever necessary during the period when
libvirt (and the Linux kernel) supported both VFIO and "legacy KVM"
styles of hostdev device assignment for QEMU. This became pointless
many years ago when legacy KVM device assignment was removed from the
kernel, and support for that style of device assignment was completely
disabled in the libvirt source in 2019 (commit
v5.6.0-316-g2e7225ea8c).
Nevertheless, there were instances of <driver name='vfio'/> in the
unit test data that were then (unnecessarily) propagated to several
more tests over the years. This patch cleans out those unnecessary
explicit settings of driver name='vfio' in all QEMU unit test data,
proving that the attribute is no longer (externally) needed while also
making it simpler to properly test when a later patch "re-animates"
the driver name attribute for a slightly different (but related) use.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
Few issues:
1) There are few bits with domain XML bits that seem to mention it:
tests/qemuhotplugtestdevices/qemuhotplug-hostdev-pci.xml: <driver
name='vfio'/>
tests/qemuhotplugtestdomains/qemuhotplug-base-live+hostdev-pci.xml: <driver
name='vfio'/>
tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+hostdev-pci.xml:
<driver name='vfio'/>
tests/qemumemlockdata/qemumemlock-pc-hardlimit+hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pc-hardlimit+locked+hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pc-hostdev-nvme.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pc-hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pc-locked+hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pseries-hardlimit+hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pseries-hardlimit+locked+hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pseries-hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pseries-locked+hostdev.xml: <driver
name='vfio'/>
tests/qemustatusxml2xmldata/modern-in.xml: <driver name='vfio'/>
2) There's documentation that seems to mention it:
docs/formatdomain.rst: <driver name='vfio'/>
docs/formatnetwork.rst: <driver name='vfio'/>
docs/formatnetworkport.rst: <driver name='vfio'/>
docs/pci-addresses.rst: <driver name='vfio'/>
3) You are not leaving any example with the existing syntax. To prevent
regression, either keep some in or create a specific new test case to
cover this now-corner-case.
With at least 2 & 3 addressed:
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
10:56 p.m.
New subject: [libvirt PATCH v2 09/15] tests: remove explicit <driver
name='vfio'/> from hostdev test cases
On 11/27/23 10:03 AM, Peter Krempa wrote:
On Mon, Nov 06, 2023 at 02:38:54 -0500, Laine Stump wrote:
> The long-deprecated use of <driver name='vfio|xen|kvm'/> in domain xml
> for <hostdev> devices was only ever necessary during the period when
> libvirt (and the Linux kernel) supported both VFIO and "legacy KVM"
> styles of hostdev device assignment for QEMU. This became pointless
> many years ago when legacy KVM device assignment was removed from the
> kernel, and support for that style of device assignment was completely
> disabled in the libvirt source in 2019 (commit
> v5.6.0-316-g2e7225ea8c).
>
> Nevertheless, there were instances of <driver name='vfio'/> in the
> unit test data that were then (unnecessarily) propagated to several
> more tests over the years. This patch cleans out those unnecessary
> explicit settings of driver name='vfio' in all QEMU unit test data,
> proving that the attribute is no longer (externally) needed while also
> making it simpler to properly test when a later patch "re-animates"
> the driver name attribute for a slightly different (but related) use.
>
> Signed-off-by: Laine Stump <laine(a)redhat.com>
> ---
Few issues:
1) There are few bits with domain XML bits that seem to mention it:
tests/qemuhotplugtestdevices/qemuhotplug-hostdev-pci.xml: <driver
name='vfio'/>
tests/qemuhotplugtestdomains/qemuhotplug-base-live+hostdev-pci.xml: <driver
name='vfio'/>
tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+hostdev-pci.xml:
<driver name='vfio'/>
I *thought* that I needed to keep those for now (until patch 12/15), but
it turns out I didn't, so I removed them too.
tests/qemumemlockdata/qemumemlock-pc-hardlimit+hostdev.xml:
<driver name='vfio'/>
tests/qemumemlockdata/qemumemlock-pc-hardlimit+locked+hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pc-hostdev-nvme.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pc-hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pc-locked+hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pseries-hardlimit+hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pseries-hardlimit+locked+hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pseries-hostdev.xml: <driver
name='vfio'/>
tests/qemumemlockdata/qemumemlock-pseries-locked+hostdev.xml: <driver
name='vfio'/>
I had previously also left these in because the test was failing when I
removed them, then I forgot to go back and investiate why. Now that
you've reminded me to look back at it, I see this failure was due to the
patch 11/15 - "conf: replace virHostdevIsVFIODevice with
virHostdevIsPCIDevice" - not yet being applied. I've switched the order
of the patches and now am able to remove these as well.
tests/qemustatusxml2xmldata/modern-in.xml: <driver
name='vfio'/>
This is status XML generated by
2) There's documentation that seems to mention it:
docs/formatdomain.rst: <driver name='vfio'/>
docs/formatnetwork.rst: <driver name='vfio'/>
docs/formatnetworkport.rst: <driver name='vfio'/>
docs/pci-addresses.rst: <driver name='vfio'/>
removed (I forgot to search in docs)
3) You are not leaving any example with the existing syntax. To prevent
regression, either keep some in or create a specific new test case to
cover this now-corner-case.
One of the test cases added in patch 12/15 covers the "legacy" case of
"driver name='vfio'" along with the new "driver
type='vfio'", and the
new usage of "driver name='vfio-pci-igbvf'".
With at least 2 & 3 addressed:
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
_______________________________________________
Devel mailing list -- devel(a)lists.libvirt.org
To unsubscribe send an email to devel-leave(a)lists.libvirt.org
1:38 a.m.
New subject: [libvirt PATCH v2 10/15] xen: explicitly set hostdev driver.type at runtime, not in postparse
Xen only supports a single type of PCI hostdev assignment, so it is
superfluous to have <driver name='xen'/> peppered throughout the
config. It *is* necessary to have the driver type explicitly set in
the hosdev object before calling into the hypervisor-agnostic "hostdev
manager" though (otherwise the hostdev manager doesn't know whether it
should do Xen-specific setup, or VFIO-specific setup).
Historically, the Xen driver has checked for "default" driver type
(i.e. not set in the XML), and set it to "xen', during the XML
postparse, thus guaranteeing that it will be set by the time the
object is sent to the hostdev manager at runtime, but also setting it
so early that a simple round-trip of parse-format results in the XML
always containing an explicit <driver name='xen'/>, even if that
wasn't specified in the original XML.
The QEMU driver *doesn't* set driver.type during postparse though;
instead, it waits until domain startup time (or device attach time for
hotplug), and sets the driver.type then. The result is that a
parse-format round trip of the XML in the QEMU driver *doesn't* add in
the <driver name='vfio'/>.
This patch modifies the Xen code to behave similarly to the QEMU code
- the PostParse just checks for a driver.type that isn't supported by
the Xen driver, and any explicit setting to "xen" is deferred until domain
runtime rather than during the postparse.
This delayed setting of driver.type of course results in slightly
different xml2xml parse-format results, so the unit test data is
modified accordingly.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/libxl/libxl_domain.c | 65 +++++++++++++++----
src/libxl/libxl_driver.c | 25 ++++---
tests/libxlxml2domconfigdata/moredevs-hvm.xml | 1 -
tests/xlconfigdata/test-fullvirt-pci.xml | 2 -
tests/xmconfigdata/test-pci-dev-syntax.xml | 2 -
tests/xmconfigdata/test-pci-devs.xml | 2 -
6 files changed, 69 insertions(+), 28 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 22482adfa6..ecdf57e655 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -160,8 +160,15 @@ libxlDomainDeviceDefPostParse(virDomainDeviceDef *dev,
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI
&&
- pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
- pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
+ pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT
&&
+ pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN) {
+
+ /* Xen only supports "Xen" style of hostdev, of course! */
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("XEN does not support device assignment mode
'%1$s'"),
+
virDeviceHostdevPCIDriverTypeToString(pcisrc->driver.type));
+ return -1;
+ }
}
if (dev->type == VIR_DOMAIN_DEVICE_VIDEO) {
@@ -986,18 +993,9 @@ libxlNetworkPrepareDevices(virDomainDef *def)
if (actualType == VIR_DOMAIN_NET_TYPE_HOSTDEV &&
net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
/* Each type='hostdev' network device must also have a
- * corresponding entry in the hostdevs array. For netdevs
- * that are hardcoded as type='hostdev', this is already
- * done by the parser, but for those allocated from a
- * network / determined at runtime, we need to do it
- * separately.
+ * corresponding entry in the hostdevs array.
*/
virDomainHostdevDef *hostdev = virDomainNetGetActualHostdev(net);
- virDomainHostdevSubsysPCI *pcisrc = &hostdev->source.subsys.u.pci;
-
- if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
- hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
- pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
if (virDomainHostdevInsert(def, hostdev) < 0)
return -1;
@@ -1007,6 +1005,46 @@ libxlNetworkPrepareDevices(virDomainDef *def)
return 0;
}
+
+static int
+libxlHostdevPrepareDevices(virDomainDef *def)
+{
+ size_t i;
+
+ for (i = 0; i < def->nhostdevs; i++) {
+ virDomainHostdevDef *hostdev = def->hostdevs[i];
+ virDomainHostdevSubsysPCI *pcisrc = &hostdev->source.subsys.u.pci;
+
+ if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
+ hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI
&&
+ pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
+
+
+ pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
+
+ /* Q: Why do we set an explicit driverType here even
+ * though Xen (currently) only supports one driverType for
+ * PCI hostdev assignment?
+ *
+ * A: Setting the driver type *in the domain XML config*
+ * is optional (and actually pointless at the time of
+ * writing, since each hypervisor only supports a single
+ * type of PCI hostdev device assignment). But the
+ * hypervisor-agnostic virHostdevPrepareDomainDevices(),
+ * which is called immediately after this function in
+ * order to do any driver-related setup (e.g. bind the
+ * host device to a driver kernel driver), requires that
+ * the driverType be explicitly set (otherwise it wouldn't
+ * know whether to bind to the Xen driver or VFIO driver,
+ * for example).
+ */
+ }
+ }
+
+ return 0;
+}
+
+
static void
libxlConsoleCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback)
{
@@ -1174,6 +1212,9 @@ libxlDomainStartPrepare(libxlDriverPrivate *driver,
if (libxlNetworkPrepareDevices(vm->def) < 0)
goto error;
+ if (libxlHostdevPrepareDevices(vm->def) < 0)
+ goto error;
+
if (virHostdevPrepareDomainDevices(hostdev_mgr, LIBXL_DRIVER_INTERNAL_NAME,
vm->def, hostdev_flags) < 0)
goto error;
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 7f12b11b8d..1636233346 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -3087,6 +3087,22 @@ libxlDomainAttachHostPCIDevice(libxlDriverPrivate *driver,
VIR_REALLOC_N(vm->def->hostdevs, vm->def->nhostdevs + 1);
+ /* The only supported driverType for Xen is
+ * VIR_DOMAIN_HOSTDEV_PCI_DRIVER_TYPE_XEN, which normally isn't
+ * set in the config (because it doesn't need to be), but it does
+ * need to be set for the impending call to
+ * virHostdevPreparePCIDevices()
+ */
+ if (pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
+ pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
+
+ if (pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("XEN does not support device assignment mode
'%1$s'"),
+ virDeviceHostdevPCIDriverTypeToString(pcisrc->driver.type));
+ goto cleanup;
+ }
+
if (virHostdevPreparePCIDevices(hostdev_mgr, LIBXL_DRIVER_INTERNAL_NAME,
vm->def->name, vm->def->uuid,
&hostdev, 1, 0) < 0)
@@ -3395,15 +3411,6 @@ libxlDomainAttachNetDevice(libxlDriverPrivate *driver,
if (actualType == VIR_DOMAIN_NET_TYPE_HOSTDEV) {
virDomainHostdevDef *hostdev = virDomainNetGetActualHostdev(net);
- virDomainHostdevSubsysPCI *pcisrc = &hostdev->source.subsys.u.pci;
-
- /* For those just allocated from a network pool whose driver type is
- * still VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT, we need to set
- * driver type correctly.
- */
- if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
- hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
- pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
/* This is really a "smart hostdev", so it should be attached
* as a hostdev (the hostdev code will reach over into the
diff --git a/tests/libxlxml2domconfigdata/moredevs-hvm.xml
b/tests/libxlxml2domconfigdata/moredevs-hvm.xml
index 89ad80631d..64eeeff889 100644
--- a/tests/libxlxml2domconfigdata/moredevs-hvm.xml
+++ b/tests/libxlxml2domconfigdata/moredevs-hvm.xml
@@ -43,7 +43,6 @@
</interface>
<interface type='hostdev' managed='yes'>
<mac address='00:16:3e:2e:e7:fc'/>
- <driver name='xen'/>
<source>
<address type='pci' domain='0x0000' bus='0x0a'
slot='0x10' function='0x0'/>
</source>
diff --git a/tests/xlconfigdata/test-fullvirt-pci.xml
b/tests/xlconfigdata/test-fullvirt-pci.xml
index 75aa6ac25b..6826d14b9e 100644
--- a/tests/xlconfigdata/test-fullvirt-pci.xml
+++ b/tests/xlconfigdata/test-fullvirt-pci.xml
@@ -37,13 +37,11 @@
<model type='cirrus' vram='8192' heads='1'
primary='yes'/>
</video>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='xen'/>
<source>
<address domain='0x0000' bus='0x01' slot='0x1a'
function='0x1'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='xen'/>
<source writeFiltering='no'>
<address domain='0x0000' bus='0x02' slot='0x00'
function='0x0'/>
</source>
diff --git a/tests/xmconfigdata/test-pci-dev-syntax.xml
b/tests/xmconfigdata/test-pci-dev-syntax.xml
index 5d5d29c61c..1d5d857072 100644
--- a/tests/xmconfigdata/test-pci-dev-syntax.xml
+++ b/tests/xmconfigdata/test-pci-dev-syntax.xml
@@ -55,13 +55,11 @@
<model type='cirrus' vram='8192' heads='1'
primary='yes'/>
</video>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='xen'/>
<source>
<address domain='0x0001' bus='0x0c' slot='0x1b'
function='0x2'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='xen'/>
<source>
<address domain='0x0000' bus='0x01' slot='0x13'
function='0x0'/>
</source>
diff --git a/tests/xmconfigdata/test-pci-devs.xml b/tests/xmconfigdata/test-pci-devs.xml
index 5d5d29c61c..1d5d857072 100644
--- a/tests/xmconfigdata/test-pci-devs.xml
+++ b/tests/xmconfigdata/test-pci-devs.xml
@@ -55,13 +55,11 @@
<model type='cirrus' vram='8192' heads='1'
primary='yes'/>
</video>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='xen'/>
<source>
<address domain='0x0001' bus='0x0c' slot='0x1b'
function='0x2'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
- <driver name='xen'/>
<source>
<address domain='0x0000' bus='0x01' slot='0x13'
function='0x0'/>
</source>
--
2.41.0
9:12 a.m.
New subject: [libvirt PATCH v2 10/15] xen: explicitly set hostdev driver.type
at runtime, not in postparse
On Mon, Nov 06, 2023 at 02:38:55 -0500, Laine Stump wrote:
Xen only supports a single type of PCI hostdev assignment, so it is
superfluous to have <driver name='xen'/> peppered throughout the
config. It *is* necessary to have the driver type explicitly set in
the hosdev object before calling into the hypervisor-agnostic "hostdev
manager" though (otherwise the hostdev manager doesn't know whether it
should do Xen-specific setup, or VFIO-specific setup).
Historically, the Xen driver has checked for "default" driver type
(i.e. not set in the XML), and set it to "xen', during the XML
postparse, thus guaranteeing that it will be set by the time the
object is sent to the hostdev manager at runtime, but also setting it
so early that a simple round-trip of parse-format results in the XML
always containing an explicit <driver name='xen'/>, even if that
wasn't specified in the original XML.
Generally stuff that is written to the definition at parse time is done
so that it doesn't change in the future, thus preserving ABI of machines
created with a config where the default was not entered yet.
This commit message doesn't make an argument why the change is needed,
so I'm a bit reluctant...
The QEMU driver *doesn't* set driver.type during postparse
though;
instead, it waits until domain startup time (or device attach time for
hotplug), and sets the driver.type then. The result is that a
parse-format round trip of the XML in the QEMU driver *doesn't* add in
the <driver name='vfio'/>.
This patch modifies the Xen code to behave similarly to the QEMU code
- the PostParse just checks for a driver.type that isn't supported by
the Xen driver, and any explicit setting to "xen" is deferred until domain
runtime rather than during the postparse.
This delayed setting of driver.type of course results in slightly
different xml2xml parse-format results, so the unit test data is
modified accordingly.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/libxl/libxl_domain.c | 65 +++++++++++++++----
src/libxl/libxl_driver.c | 25 ++++---
tests/libxlxml2domconfigdata/moredevs-hvm.xml | 1 -
tests/xlconfigdata/test-fullvirt-pci.xml | 2 -
tests/xmconfigdata/test-pci-dev-syntax.xml | 2 -
tests/xmconfigdata/test-pci-devs.xml | 2 -
6 files changed, 69 insertions(+), 28 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 22482adfa6..ecdf57e655 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -160,8 +160,15 @@ libxlDomainDeviceDefPostParse(virDomainDeviceDef *dev,
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI
&&
- pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
- pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
+ pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT
&&
+ pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN) {
+
+ /* Xen only supports "Xen" style of hostdev, of course! */
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("XEN does not support device assignment mode
'%1$s'"),
+
virDeviceHostdevPCIDriverTypeToString(pcisrc->driver.type));
+ return -1;
+ }
}
if (dev->type == VIR_DOMAIN_DEVICE_VIDEO) {
@@ -986,18 +993,9 @@ libxlNetworkPrepareDevices(virDomainDef *def)
if (actualType == VIR_DOMAIN_NET_TYPE_HOSTDEV &&
net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
/* Each type='hostdev' network device must also have a
- * corresponding entry in the hostdevs array. For netdevs
- * that are hardcoded as type='hostdev', this is already
- * done by the parser, but for those allocated from a
- * network / determined at runtime, we need to do it
- * separately.
+ * corresponding entry in the hostdevs array.
*/
virDomainHostdevDef *hostdev = virDomainNetGetActualHostdev(net);
- virDomainHostdevSubsysPCI *pcisrc = &hostdev->source.subsys.u.pci;
-
- if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
- hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
- pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
if (virDomainHostdevInsert(def, hostdev) < 0)
return -1;
@@ -1007,6 +1005,46 @@ libxlNetworkPrepareDevices(virDomainDef *def)
return 0;
}
+
+static int
+libxlHostdevPrepareDevices(virDomainDef *def)
+{
+ size_t i;
+
+ for (i = 0; i < def->nhostdevs; i++) {
+ virDomainHostdevDef *hostdev = def->hostdevs[i];
+ virDomainHostdevSubsysPCI *pcisrc = &hostdev->source.subsys.u.pci;
+
+ if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
+ hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI
&&
+ pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
+
... and here I don't think it's obvious enough that the default must
never change.
12:14 a.m.
New subject: [libvirt PATCH v2 10/15] xen: explicitly set hostdev driver.type
at runtime, not in postparse
On 11/27/23 10:12 AM, Peter Krempa wrote:
On Mon, Nov 06, 2023 at 02:38:55 -0500, Laine Stump wrote:
> Xen only supports a single type of PCI hostdev assignment, so it is
> superfluous to have <driver name='xen'/> peppered throughout the
> config. It *is* necessary to have the driver type explicitly set in
> the hosdev object before calling into the hypervisor-agnostic "hostdev
> manager" though (otherwise the hostdev manager doesn't know whether it
> should do Xen-specific setup, or VFIO-specific setup).
>
> Historically, the Xen driver has checked for "default" driver type
> (i.e. not set in the XML), and set it to "xen', during the XML
> postparse, thus guaranteeing that it will be set by the time the
> object is sent to the hostdev manager at runtime, but also setting it
> so early that a simple round-trip of parse-format results in the XML
> always containing an explicit <driver name='xen'/>, even if that
> wasn't specified in the original XML.
Generally stuff that is written to the definition at parse time is done
so that it doesn't change in the future, thus preserving ABI of machines
created with a config where the default was not entered yet.
I don't think there was any intentional "lock in the default setting in
the config to preserve ABI" in this case - it all seems to just be
convenience/serendipity. From what I can see in the original code adding
"PCI passthrough" to the libxl driver, they were just filling in the
driver name in the xml because 1) it was there, and 2) they had just
split out some of the code from qemu into "common code" to be used by
both libxl and QEMU, needed a way to specify which driver was calling
into this common code, saw the driver name as a convenient way to do it,
and noticed that lots of other values that weren't set by the user were
being set in the postparse, so that's where they set it in their code.
(BTW, there was code in the original commit adding PCI passthrough to
libxl (commit 6225cb3df5a5732868719462f0a602ef11f7fa03) that logged an
error if the driver name was anything other than empty (in which case it
was set to "xen") or "xen". That code is still there today (see
libxlNodeDeviceDetachFlags), so the Xen driver definiteoy only supports
the one type of PCI device assignment.)
This commit message doesn't make an argument why the change is needed,
so I'm a bit reluctant...
Well... the less use of the old usage of <driver name> there is, the
better, and preventing it from being written into every single new
config file with a <hostdev> means less use. Also this change makes the
libxl driver more consistent with the behavior of the qemu driver (which
has never set an explicit default in the postparse - it waits until the
devices are being initialized for domain startup/hotplug before it sets
the driver type (and it also always sets it to the same value).
I suppose I could omit this patch, but I think it's just perpetuating
unintentional code that is inconsistent with the other driver (qemu)
which serves to make it more difficult for a newcomer to understand
what's going on with the <driver name/type> and what is the proper way
to handle it in the case of some new hypervisor driver that decides to
support <hostdev>.
> The QEMU driver *doesn't* set driver.type during postparse though;
> instead, it waits until domain startup time (or device attach time for
> hotplug), and sets the driver.type then. The result is that a
> parse-format round trip of the XML in the QEMU driver *doesn't* add in
> the <driver name='vfio'/>.
>
> This patch modifies the Xen code to behave similarly to the QEMU code
> - the PostParse just checks for a driver.type that isn't supported by
> the Xen driver, and any explicit setting to "xen" is deferred until domain
> runtime rather than during the postparse.
>
> This delayed setting of driver.type of course results in slightly
> different xml2xml parse-format results, so the unit test data is
> modified accordingly.
>
> Signed-off-by: Laine Stump <laine(a)redhat.com>
> ---
> src/libxl/libxl_domain.c | 65 +++++++++++++++----
> src/libxl/libxl_driver.c | 25 ++++---
> tests/libxlxml2domconfigdata/moredevs-hvm.xml | 1 -
> tests/xlconfigdata/test-fullvirt-pci.xml | 2 -
> tests/xmconfigdata/test-pci-dev-syntax.xml | 2 -
> tests/xmconfigdata/test-pci-devs.xml | 2 -
> 6 files changed, 69 insertions(+), 28 deletions(-)
>
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 22482adfa6..ecdf57e655 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -160,8 +160,15 @@ libxlDomainDeviceDefPostParse(virDomainDeviceDef *dev,
>
> if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI
&&
> - pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
> - pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
> + pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT
&&
> + pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN) {
> +
> + /* Xen only supports "Xen" style of hostdev, of course! */
> + virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> + _("XEN does not support device assignment mode
'%1$s'"),
> +
virDeviceHostdevPCIDriverTypeToString(pcisrc->driver.type));
> + return -1;
> + }
> }
>
> if (dev->type == VIR_DOMAIN_DEVICE_VIDEO) {
> @@ -986,18 +993,9 @@ libxlNetworkPrepareDevices(virDomainDef *def)
> if (actualType == VIR_DOMAIN_NET_TYPE_HOSTDEV &&
> net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
> /* Each type='hostdev' network device must also have a
> - * corresponding entry in the hostdevs array. For netdevs
> - * that are hardcoded as type='hostdev', this is already
> - * done by the parser, but for those allocated from a
> - * network / determined at runtime, we need to do it
> - * separately.
> + * corresponding entry in the hostdevs array.
> */
> virDomainHostdevDef *hostdev = virDomainNetGetActualHostdev(net);
> - virDomainHostdevSubsysPCI *pcisrc =
&hostdev->source.subsys.u.pci;
> -
> - if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> - hostdev->source.subsys.type ==
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
> - pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
>
> if (virDomainHostdevInsert(def, hostdev) < 0)
> return -1;
> @@ -1007,6 +1005,46 @@ libxlNetworkPrepareDevices(virDomainDef *def)
> return 0;
> }
>
> +
> +static int
> +libxlHostdevPrepareDevices(virDomainDef *def)
> +{
> + size_t i;
> +
> + for (i = 0; i < def->nhostdevs; i++) {
> + virDomainHostdevDef *hostdev = def->hostdevs[i];
> + virDomainHostdevSubsysPCI *pcisrc = &hostdev->source.subsys.u.pci;
> +
> + if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> + hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI
&&
> + pcisrc->driver.type == VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
> +
... and here I don't think it's obvious enough that the default must
never change.
But is that the case? (that the default must never change, I mean) It's
only going to make a difference if libxl adds support for some other
type of PCI device assignment *and* there is something in that new type
of device assignment that changes the guest ABI in an incompatible way.
(I'm not certain, but I'm guessing that Xen doesn't live migration of
domains with an assigned PCI device, so likely any guest would need to
be fully shut down to move from the existing type of device assignment
to some hypothetical new type that may exist at some time in the future.
At the time that VFIO device assignment first became available, there
was no <driver name='kvm'/> in any existing config, and no existing
management app had a setting for the type of device assignment. This
turned out to be a very *good* thing, because it meant that everyone
began using VFIO device assignment by default immediately even on
existing configs (and the newly-introduced <driver name='kvm|vfio'/> was
only used if someone found a problem in VFIO and needed to temporarily
switch back to KVM; fortunately I don't think anyone ever did).
If we had instead required an explicit change to config for anyone to
switch to using VFIO device assignment instead of legacy KVM device
assignment (in addition to also requiring the management applications to
add a knob to turn it on) it surely would have taken *years* longer for
VFIO to be fully accepted/adopted, and it would have been a
correspondingly longer time before the legacy KVM device assignment code
could be deprecated and then finally removed from the kernel and qemu.
Anyway, I don't see an advantage to explicitly writing into the config
the value of a knob that only has one valid setting. If, at some point
in the future, it turns out that libxl adds some new type of device
assignment, and that new type of device assignement is incompatible with
the current device assignment in such a way that they don't want users
to automatically begin using it, then at that time it can just be
explicitly stated that "not having the driver type set in the config
means that the type is "legacy xen". But maybe that *won't* be needed,
and it will be totally okay for everyone to just automatically start
using this hypothetical "new type of device assignment for libxl"; why
make the decision now that we shouldn't allow that?
So have I convinced you, or should I drop it?
2:58 a.m.
New subject: [libvirt PATCH v2 10/15] xen: explicitly set hostdev driver.type
at runtime, not in postparse
On Mon, Dec 18, 2023 at 01:14:55 -0500, Laine Stump wrote:
On 11/27/23 10:12 AM, Peter Krempa wrote:
> On Mon, Nov 06, 2023 at 02:38:55 -0500, Laine Stump wrote:
> > Xen only supports a single type of PCI hostdev assignment, so it is
> > superfluous to have <driver name='xen'/> peppered throughout the
> > config. It *is* necessary to have the driver type explicitly set in
> > the hosdev object before calling into the hypervisor-agnostic "hostdev
> > manager" though (otherwise the hostdev manager doesn't know whether
it
> > should do Xen-specific setup, or VFIO-specific setup).
> >
> > Historically, the Xen driver has checked for "default" driver type
> > (i.e. not set in the XML), and set it to "xen', during the XML
> > postparse, thus guaranteeing that it will be set by the time the
> > object is sent to the hostdev manager at runtime, but also setting it
> > so early that a simple round-trip of parse-format results in the XML
> > always containing an explicit <driver name='xen'/>, even if that
> > wasn't specified in the original XML.
>
> Generally stuff that is written to the definition at parse time is done
> so that it doesn't change in the future, thus preserving ABI of machines
> created with a config where the default was not entered yet.
I don't think there was any intentional "lock in the default setting in the
config to preserve ABI" in this case - it all seems to just be
convenience/serendipity. From what I can see in the original code adding
"PCI passthrough" to the libxl driver, they were just filling in the driver
name in the xml because 1) it was there, and 2) they had just split out some
of the code from qemu into "common code" to be used by both libxl and QEMU,
needed a way to specify which driver was calling into this common code, saw
the driver name as a convenient way to do it, and noticed that lots of other
values that weren't set by the user were being set in the postparse, so
that's where they set it in their code.
(BTW, there was code in the original commit adding PCI passthrough to libxl
(commit 6225cb3df5a5732868719462f0a602ef11f7fa03) that logged an error if
the driver name was anything other than empty (in which case it was set to
"xen") or "xen". That code is still there today (see
libxlNodeDeviceDetachFlags), so the Xen driver definiteoy only supports the
one type of PCI device assignment.)
>
> This commit message doesn't make an argument why the change is needed,
> so I'm a bit reluctant...
Well... the less use of the old usage of <driver name> there is, the better,
and preventing it from being written into every single new config file with
a <hostdev> means less use. Also this change makes the libxl driver more
consistent with the behavior of the qemu driver (which has never set an
explicit default in the postparse - it waits until the devices are being
initialized for domain startup/hotplug before it sets the driver type (and
it also always sets it to the same value).
I suppose I could omit this patch, but I think it's just perpetuating
unintentional code that is inconsistent with the other driver (qemu) which
serves to make it more difficult for a newcomer to understand what's going
on with the <driver name/type> and what is the proper way to handle it in
the case of some new hypervisor driver that decides to support <hostdev>.
>
>
> > The QEMU driver *doesn't* set driver.type during postparse though;
> > instead, it waits until domain startup time (or device attach time for
> > hotplug), and sets the driver.type then. The result is that a
> > parse-format round trip of the XML in the QEMU driver *doesn't* add in
> > the <driver name='vfio'/>.
> >
> > This patch modifies the Xen code to behave similarly to the QEMU code
> > - the PostParse just checks for a driver.type that isn't supported by
> > the Xen driver, and any explicit setting to "xen" is deferred until
domain
> > runtime rather than during the postparse.
> >
> > This delayed setting of driver.type of course results in slightly
> > different xml2xml parse-format results, so the unit test data is
> > modified accordingly.
> >
> > Signed-off-by: Laine Stump <laine(a)redhat.com>
> > ---
> > src/libxl/libxl_domain.c | 65 +++++++++++++++----
> > src/libxl/libxl_driver.c | 25 ++++---
> > tests/libxlxml2domconfigdata/moredevs-hvm.xml | 1 -
> > tests/xlconfigdata/test-fullvirt-pci.xml | 2 -
> > tests/xmconfigdata/test-pci-dev-syntax.xml | 2 -
> > tests/xmconfigdata/test-pci-devs.xml | 2 -
> > 6 files changed, 69 insertions(+), 28 deletions(-)
> >
> > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > index 22482adfa6..ecdf57e655 100644
> > --- a/src/libxl/libxl_domain.c
> > +++ b/src/libxl/libxl_domain.c
> > @@ -160,8 +160,15 @@ libxlDomainDeviceDefPostParse(virDomainDeviceDef *dev,
> > if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> > hostdev->source.subsys.type ==
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
> > - pcisrc->driver.type ==
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT)
> > - pcisrc->driver.type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
> > + pcisrc->driver.type !=
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT &&
> > + pcisrc->driver.type != VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN)
{
> > +
> > + /* Xen only supports "Xen" style of hostdev, of course!
*/
> > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> > + _("XEN does not support device assignment mode
'%1$s'"),
> > +
virDeviceHostdevPCIDriverTypeToString(pcisrc->driver.type));
> > + return -1;
> > + }
> > }
> > if (dev->type == VIR_DOMAIN_DEVICE_VIDEO) {
> > @@ -986,18 +993,9 @@ libxlNetworkPrepareDevices(virDomainDef *def)
> > if (actualType == VIR_DOMAIN_NET_TYPE_HOSTDEV &&
> > net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
> > /* Each type='hostdev' network device must also have a
> > - * corresponding entry in the hostdevs array. For netdevs
> > - * that are hardcoded as type='hostdev', this is already
> > - * done by the parser, but for those allocated from a
> > - * network / determined at runtime, we need to do it
> > - * separately.
> > + * corresponding entry in the hostdevs array.
> > */
> > virDomainHostdevDef *hostdev =
virDomainNetGetActualHostdev(net);
> > - virDomainHostdevSubsysPCI *pcisrc =
&hostdev->source.subsys.u.pci;
> > -
> > - if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> > - hostdev->source.subsys.type ==
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
> > - pcisrc->driver.type =
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
> > if (virDomainHostdevInsert(def, hostdev) < 0)
> > return -1;
> > @@ -1007,6 +1005,46 @@ libxlNetworkPrepareDevices(virDomainDef *def)
> > return 0;
> > }
> > +
> > +static int
> > +libxlHostdevPrepareDevices(virDomainDef *def)
> > +{
> > + size_t i;
> > +
> > + for (i = 0; i < def->nhostdevs; i++) {
> > + virDomainHostdevDef *hostdev = def->hostdevs[i];
> > + virDomainHostdevSubsysPCI *pcisrc =
&hostdev->source.subsys.u.pci;
> > +
> > + if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
> > + hostdev->source.subsys.type ==
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
> > + pcisrc->driver.type ==
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_DEFAULT) {
> > +
>
> ... and here I don't think it's obvious enough that the default must
> never change.
But is that the case? (that the default must never change, I mean) It's only
going to make a difference if libxl adds support for some other type of PCI
device assignment *and* there is something in that new type of device
assignment that changes the guest ABI in an incompatible way. (I'm not
certain, but I'm guessing that Xen doesn't live migration of domains with an
assigned PCI device, so likely any guest would need to be fully shut down to
move from the existing type of device assignment to some hypothetical new
type that may exist at some time in the future.
At the time that VFIO device assignment first became available, there was no
<driver name='kvm'/> in any existing config, and no existing management
app
had a setting for the type of device assignment. This turned out to be a
very *good* thing, because it meant that everyone began using VFIO device
assignment by default immediately even on existing configs (and the
newly-introduced <driver name='kvm|vfio'/> was only used if someone found
a
problem in VFIO and needed to temporarily switch back to KVM; fortunately I
don't think anyone ever did).
If we had instead required an explicit change to config for anyone to switch
to using VFIO device assignment instead of legacy KVM device assignment (in
addition to also requiring the management applications to add a knob to turn
it on) it surely would have taken *years* longer for VFIO to be fully
accepted/adopted, and it would have been a correspondingly longer time
before the legacy KVM device assignment code could be deprecated and then
finally removed from the kernel and qemu.
Anyway, I don't see an advantage to explicitly writing into the config the
value of a knob that only has one valid setting. If, at some point in the
future, it turns out that libxl adds some new type of device assignment, and
that new type of device assignement is incompatible with the current device
assignment in such a way that they don't want users to automatically begin
using it, then at that time it can just be explicitly stated that "not
having the driver type set in the config means that the type is "legacy
xen". But maybe that *won't* be needed, and it will be totally okay for
everyone to just automatically start using this hypothetical "new type of
device assignment for libxl"; why make the decision now that we shouldn't
allow that?
So have I convinced you, or should I drop it?
The explanation makes sense. You can mention in the commit message that
this is mostly a backend thing so it's likely that it can be upgraded in
the future in a compatible way.
Ideally add a comment to the xen function stating that it can change if
it's ABI compatible.
1:38 a.m.
New subject: [libvirt PATCH v2 11/15] conf: replace virHostdevIsVFIODevice with virHostdevIsPCIDevice
virHostdevIsVFIODevice() and virDomainDefHasVFIOHostdev() are only ever
called from the QEMU driver, and in the case of the QEMU driver, any
PCI hostdev by definition uses VFIO, so really all these callers only
need to know if the device is a PCI hostdev.
(It turned out that the less specific virHostdevIsPCIDevice() already
existed in hypervisor/virhostdev.c, so I had to remove one of them;
since conf is a lower level directory than hypervisor, and the
function is called from conf, keeping the copy in hypervisor would
have required moving its caller (virDomainDefHasPCIHostdev()) into
hypervisor as well, so I just removed the copy in hypervisor.)
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/domain_conf.c | 13 ++++++-------
src/conf/domain_conf.h | 4 ++--
src/hypervisor/virhostdev.c | 8 --------
src/hypervisor/virhostdev.h | 2 --
src/libvirt_private.syms | 5 ++---
src/qemu/qemu_domain.c | 6 +++---
src/qemu/qemu_hostdev.c | 2 +-
src/qemu/qemu_hotplug.c | 2 +-
8 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index d87ead291c..04d9de7f32 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -30576,12 +30576,12 @@ virDomainDefHasNVMeDisk(const virDomainDef *def)
bool
-virDomainDefHasVFIOHostdev(const virDomainDef *def)
+virDomainDefHasPCIHostdev(const virDomainDef *def)
{
size_t i;
for (i = 0; i < def->nhostdevs; i++) {
- if (virHostdevIsVFIODevice(def->hostdevs[i]))
+ if (virHostdevIsPCIDevice(def->hostdevs[i]))
return true;
}
@@ -30852,17 +30852,16 @@ virHostdevIsMdevDevice(const virDomainHostdevDef *hostdev)
/**
- * virHostdevIsVFIODevice:
+ * virHostdevIsPCIDevice:
* @hostdev: host device to check
*
- * Returns true if @hostdev is a PCI device with VFIO backend, false otherwise.
+ * Returns true if @hostdev is a PCI device, false otherwise.
*/
bool
-virHostdevIsVFIODevice(const virDomainHostdevDef *hostdev)
+virHostdevIsPCIDevice(const virDomainHostdevDef *hostdev)
{
return hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
- hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI &&
- hostdev->source.subsys.u.pci.driver.type ==
VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
+ hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI;
}
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 855e09d236..3ff02ec636 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -4405,7 +4405,7 @@ bool
virDomainDefHasNVMeDisk(const virDomainDef *def);
bool
-virDomainDefHasVFIOHostdev(const virDomainDef *def);
+virDomainDefHasPCIHostdev(const virDomainDef *def);
bool
virDomainDefHasMdevHostdev(const virDomainDef *def);
@@ -4463,7 +4463,7 @@ bool
virHostdevIsMdevDevice(const virDomainHostdevDef *hostdev)
ATTRIBUTE_NONNULL(1);
bool
-virHostdevIsVFIODevice(const virDomainHostdevDef *hostdev)
+virHostdevIsPCIDevice(const virDomainHostdevDef *hostdev)
ATTRIBUTE_NONNULL(1);
int
diff --git a/src/hypervisor/virhostdev.c b/src/hypervisor/virhostdev.c
index a33b3b604f..e0ad1371c2 100644
--- a/src/hypervisor/virhostdev.c
+++ b/src/hypervisor/virhostdev.c
@@ -344,14 +344,6 @@ virHostdevNetDevice(virDomainHostdevDef *hostdev,
}
-bool
-virHostdevIsPCIDevice(const virDomainHostdevDef *hostdev)
-{
- return hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
- hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI;
-}
-
-
static bool
virHostdevIsPCINetDevice(const virDomainHostdevDef *hostdev)
{
diff --git a/src/hypervisor/virhostdev.h b/src/hypervisor/virhostdev.h
index 642d753ffb..22ec3068db 100644
--- a/src/hypervisor/virhostdev.h
+++ b/src/hypervisor/virhostdev.h
@@ -232,5 +232,3 @@ virHostdevUpdateActiveNVMeDevices(virHostdevManager *hostdev_mgr,
const char *dom_name,
virDomainDiskDef **disks,
size_t ndisks);
-
-bool virHostdevIsPCIDevice(const virDomainHostdevDef *hostdev);
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 479a69ed0b..a943a79e01 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -340,11 +340,11 @@ virDomainDefHasMemoryHotplug;
virDomainDefHasNVMeDisk;
virDomainDefHasOldStyleROUEFI;
virDomainDefHasOldStyleUEFI;
+virDomainDefHasPCIHostdev;
virDomainDefHasSpiceGraphics;
virDomainDefHasUSB;
virDomainDefHasVcpusOffline;
virDomainDefHasVDPANet;
-virDomainDefHasVFIOHostdev;
virDomainDefLifecycleActionAllowed;
virDomainDefMaybeAddController;
virDomainDefMaybeAddInput;
@@ -777,8 +777,8 @@ virDomainEventWatchdogNewFromObj;
virDomainQemuMonitorEventNew;
virDomainQemuMonitorEventStateRegisterID;
virHostdevIsMdevDevice;
+virHostdevIsPCIDevice;
virHostdevIsSCSIDevice;
-virHostdevIsVFIODevice;
# conf/domain_nwfilter.h
@@ -1641,7 +1641,6 @@ virCloseCallbacksDomainRunForConn;
# hypervisor/virhostdev.h
virHostdevFindUSBDevice;
-virHostdevIsPCIDevice;
virHostdevManagerGetDefault;
virHostdevPCINodeDeviceDetach;
virHostdevPCINodeDeviceReAttach;
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 09735ba710..37055fd6be 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -9380,7 +9380,7 @@ getPPC64MemLockLimitBytes(virDomainDef *def)
for (i = 0; i < def->nhostdevs; i++) {
virDomainHostdevDef *dev = def->hostdevs[i];
- if (virHostdevIsVFIODevice(dev)) {
+ if (virHostdevIsPCIDevice(dev)) {
pciAddr = &dev->source.subsys.u.pci.addr;
if (virPCIDeviceAddressIsValid(pciAddr, false)) {
@@ -9485,7 +9485,7 @@ qemuDomainGetNumVFIOHostdevs(const virDomainDef *def)
int n = 0;
for (i = 0; i < def->nhostdevs; i++) {
- if (virHostdevIsVFIODevice(def->hostdevs[i]) ||
+ if (virHostdevIsPCIDevice(def->hostdevs[i]) ||
virHostdevIsMdevDevice(def->hostdevs[i]))
n++;
}
@@ -10526,7 +10526,7 @@ qemuDomainSupportsVideoVga(const virDomainVideoDef *video,
bool
qemuDomainNeedsVFIO(const virDomainDef *def)
{
- return virDomainDefHasVFIOHostdev(def) ||
+ return virDomainDefHasPCIHostdev(def) ||
virDomainDefHasMdevHostdev(def) ||
virDomainDefHasNVMeDisk(def);
}
diff --git a/src/qemu/qemu_hostdev.c b/src/qemu/qemu_hostdev.c
index 4992c23ee0..15b543dbff 100644
--- a/src/qemu/qemu_hostdev.c
+++ b/src/qemu/qemu_hostdev.c
@@ -133,7 +133,7 @@ qemuHostdevUpdateActiveDomainDevices(virQEMUDriver *driver,
bool
qemuHostdevNeedsVFIO(const virDomainHostdevDef *hostdev)
{
- return virHostdevIsVFIODevice(hostdev) ||
+ return virHostdevIsPCIDevice(hostdev) ||
virHostdevIsMdevDevice(hostdev);
}
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index fec7c4be4e..dd2062a05b 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -4681,7 +4681,7 @@ qemuDomainRemoveHostDevice(virQEMUDriver *driver,
virDomainAuditHostdev(vm, hostdev, "detach", true);
- if (!virHostdevIsVFIODevice(hostdev) &&
+ if (!virHostdevIsPCIDevice(hostdev) &&
qemuSecurityRestoreHostdevLabel(driver, vm, hostdev) < 0)
VIR_WARN("Failed to restore host device labelling");
--
2.41.0
9:24 a.m.
New subject: [libvirt PATCH v2 11/15] conf: replace virHostdevIsVFIODevice
with virHostdevIsPCIDevice
On Mon, Nov 06, 2023 at 02:38:56 -0500, Laine Stump wrote:
virHostdevIsVFIODevice() and virDomainDefHasVFIOHostdev() are only
ever
called from the QEMU driver, and in the case of the QEMU driver, any
PCI hostdev by definition uses VFIO, so really all these callers only
need to know if the device is a PCI hostdev.
(It turned out that the less specific virHostdevIsPCIDevice() already
existed in hypervisor/virhostdev.c, so I had to remove one of them;
since conf is a lower level directory than hypervisor, and the
function is called from conf, keeping the copy in hypervisor would
have required moving its caller (virDomainDefHasPCIHostdev()) into
hypervisor as well, so I just removed the copy in hypervisor.)
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/conf/domain_conf.c | 13 ++++++-------
src/conf/domain_conf.h | 4 ++--
src/hypervisor/virhostdev.c | 8 --------
src/hypervisor/virhostdev.h | 2 --
src/libvirt_private.syms | 5 ++---
src/qemu/qemu_domain.c | 6 +++---
src/qemu/qemu_hostdev.c | 2 +-
src/qemu/qemu_hotplug.c | 2 +-
8 files changed, 15 insertions(+), 27 deletions(-)
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
1:38 a.m.
New subject: [libvirt PATCH v2 12/15] conf: support manually specifying VFIO variant driver in <hostdev> XML
This patch makes it possible to manually specify which VFIO variant
driver to use for PCI hostdev device assignment, so that, e.g. you
could force use of the generic vfio-pci driver with
<driver name='vfio-pci'/>
when libvirt would have normally (after applying a subsequent patch)
found a "better match" for a device in the active kernel's
modules.alias file. (The main use of this manual override would be to
work around a bug in a new VFIO variant driver by temporarily not
using that driver).
This sounds like a simple addition to XML parsing/formatting, but of
course it's messier than that, since the attribute we want to use was
previously used in config for a now non-existent purpose (choosing a
type of device assignment that was removed from the kernel nearly a
decade ago), and continues to be used *internal to the C code*.
Background:
Beginning when VFIO device assignment support was added to <hostdev>
or <interface type='hostdev'/>) in libvirt's QEMU driver, it was
possible to specify which device assignment backend to use with
"<driver name='vfio|kvm'/>". This was only useful for a couple of
years in the early 2010's when VFIO device assignment was newly
introduced, but "legacy KVM" device assignment was still possible (in
reality "<driver name='blah'/>" was only intended to be used (1)
in
the *very* early days of VFIO when "kvm" was still the default, or (2)
when the host kernel was too old to have VFIO support (meaning it was
e.g. pre-RHEL7) or (3) some bug was encountered with the then-new VFIO
code that could have been avoided by switching back to the older style
of device assignment (I don't recall anyone ever needing to set it for
this reason, but that is one of the main reasons we added the knob).
Later, when the libxl (Xen) driver in libvirt began supporting "device
passthrough" with <hostdev>, they added <driver name='xen'/> to
indicate that mode of operation. But in practice this was also never
necessary in any config, since Xen only supports one type of device
assignment, and so the attribute was anyway set in the C object by the
libxl driver code prior to calling any hypervisor-common code
(i.e. the stuff in hypervisor/hostdev.c and util/virpci.c) that needs
to know which type of device assignment is being used - setting it in
the XML config was superfluous (kind of like me saying "I am now
describing this patch in a human language", ref: Perd Hapley on "Parks
and Recreation").
So the setting was available in the XML, but never needed to be set by
the user. Because it was automatically set in the C code though,
sometimes libvirt-generated XML would contain the option even though
the user hadn't included it in the original input XML (e.g. the libxl
driver sets it in the PostParse, so all saved configs with a PCI
<hostdev> device will have <driver name='xen'/>; also status XML from
the QEMU and libxl drivers will contain <driver name='vfio|xen'/> - in
both cases completely unnecessary and redundant information).
When adding support for specifying a variant driver for VFIO device
assignment, from the beginning I have wanted to use <driver
name='blah'/> to force a specific variant driver (e.g. <driver
name='mlx5_vfio_pci'/>), with the assumption that the name attribute
could be easily repurposed because it had been *completely* unused for
so long. What I discovered though, was that 1) the field in the C
object corresponding to driver name was an enum value rather than a
string (so parser and formatter need to be changed, not just the
driver code looking at a string in the C object), and 2) even though
the XML attribute was effectively unused (except in some output), the
field in the C object was *always* being set internally as a way for
the hypervisor driver code to inform the hypervisor-common hostdev
manager (in src/hypervisor) which method of device assignment to
use. So re-use wasn't as simple as I'd wished.
However.
What I have hit upon that permits us to use
<driver name='mlx5_vfio_pci'/> is to do the following:
1) rename the existing driver name attribute to driver *type* - this
will now be the enum that is set internally by the hypervisor
driver prior to calling the hostdev manager (and also is what will
show up in status XML; the libxl driver was modified in a previous
patch so that the setting isn't done until domain runtime (rather
than during PostParse), so it will no longer show up in
regurgitated libxml config)
2) add a new attribute with the now-newly-unused name "name" - this
will be a string that can be used to communicate a specific host
kernel driver to the hostdev manager.
3) In the parsing code for <driver>, if <driver name='vfio|xen|kvm'/>
is encountered, set the driver *type* to the appropriate enum
instead, and clear our the name string. (since the four places
that use the hostdev <driver> element now all call a common parser
function, this check is only needed in a single place)
I could alternately just leave "name" as-is, and create a new
attribute with a never-before-used name within driver. I suppose
instead of "type" and "name", we could instead have "name and
"model"
(where "model" would be the string that could be set to
"mlx5_vfio_pci"). I just prefer type/name to name/model, and think
it's been long enough since <driver name='blah'/> has had a useful
purpose (and the fixup for backward compatibility is limited to a few
lines in one function) that this change is safe.
(another alternate would be to add an extra parameter to the C API
that calls into the hostdev manager rather than keeping/adding the
publicly visible "type" attribute, but it seems at least possible that
sometime in the future another alternate "type" of device assignment
could be introduced for either Xen or QEMU, and we would then need to
add back the XML attribute anyway)
I'd be fine with doing it one of the other ways, but decided to post
this way first, since it's the one that I find the most aesthetically
pleasing :-)
Note that a few test cases have been modified - places where an
existing "name='vfio'" was changed to "type='vfio'"
were in in status
XML or only the *output* XML for a test (except the case of the
virnetworkportxml2xmltest, which doesn't have a separate directory for
the XML result; fortunately the converged parsing of <driver> between
domain/network/networkport means that the test cases for network and
domain XML are already testing the same code that would convert "name"
to "type" in thte networkport XML)
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
docs/formatdomain.rst | 55 +++++++++++++------
src/conf/device_conf.c | 29 +++++++++-
src/conf/device_conf.h | 4 ++
src/conf/domain_conf.c | 1 +
src/conf/network_conf.c | 2 +
src/conf/schemas/basictypes.rng | 21 ++++---
src/conf/virnetworkportdef.c | 1 +
tests/networkxml2xmlin/hostdev-pf-old.xml | 8 +++
tests/networkxml2xmlin/hostdev-pf.xml | 2 +-
tests/networkxml2xmlout/hostdev-pf-old.xml | 8 +++
tests/networkxml2xmlout/hostdev-pf.xml | 2 +-
tests/networkxml2xmltest.c | 6 ++
.../qemuhotplug-hostdev-pci.xml | 1 -
.../qemuhotplug-base-live+hostdev-pci.xml | 2 +-
...uhotplug-pseries-base-live+hostdev-pci.xml | 2 +-
tests/qemustatusxml2xmldata/modern-in.xml | 2 +-
.../hostdev-vfio.x86_64-latest.args | 5 +-
tests/qemuxml2argvdata/hostdev-vfio.xml | 18 ++++++
.../hostdev-vfio.x86_64-latest.xml | 23 +++++++-
.../plug-hostdev-pci-unmanaged.xml | 2 +-
.../plug-hostdev-pci.xml | 2 +-
21 files changed, 161 insertions(+), 35 deletions(-)
create mode 100644 tests/networkxml2xmlin/hostdev-pf-old.xml
create mode 100644 tests/networkxml2xmlout/hostdev-pf-old.xml
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 459815d2b5..d67421a054 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -4500,24 +4500,47 @@ or:
an error. See the `Device Addresses`_ section for more details on the address
element.
``driver``
- PCI devices can have an optional ``driver`` subelement that specifies which
- backend driver to use for PCI device assignment. Use the ``name`` attribute
- to select either "vfio" (for the new VFIO device assignment backend, which
is
- compatible with UEFI SecureBoot) or "kvm" (the legacy device assignment
- handled directly by the KVM kernel module) :since:`Since 1.0.5 (QEMU and KVM
- only, requires kernel 3.6 or newer)` . When specified, device assignment will
- fail if the requested method of device assignment isn't available on the
- host. When not specified, the default is "vfio" on systems where the VFIO
- driver is available and loaded, and "kvm" on older systems, or those where
- the VFIO driver hasn't been loaded :since:`Since 1.1.3` (prior to that the
- default was always "kvm").
+ PCI hostdev devices can have an optional ``driver`` subelement that
+ specifies which host driver to bind to the device when preparing it
+ for assignment to a guest. :since:`Since 9.10.0 (useful for QEMU and
+ KVM only)`. This is done by setting the ``<driver>`` element's ``name``
+ attribute, for example::
+
+ ...
+ <hostdev mode='subsystem' type='pci' managed='yes'>
+ <driver name='vfio-pci-igb'/>
+ ...
+
+ tells libvirt to bind the driver "vfio-pci-igb" to the device on
+ the host before handing it off to QEMU for assignment to the
+ guest. Normally libvirt will bind the device to the "best match"
+ VFIO-type driver that it finds in the kernel's modules.alias file
+ (based on matching the corresponding fields of the device's
+ modalias file in sysfs) or to the generic "vfio-pci" driver if no
+ better match is found (vfio-pci is always used prior to libvirt
+ 9.10.0), but in cases when the correct driver isn't listed in
+ modules.alias then the desired device-specific driver can be forced
+ by setting driver name, or if the device-specific driver that is
+ found is "problematic" in some way, the generic vfio-pci driver
+ similarly be forced.
+
+ (Note: in versions of libvirt prior to 9.10.0 (:since:`Since
+ 1.0.5), the ``name`` attribute was described to be used to select
+ the type of device assignment ("vfio", "kvm", or "xen"),
but those
+ values have been mostly useless, since the type of device
+ assignment is actually determined by which hypservisor is in
+ use. This means that you may occasionally see ``<driver
+ name='vfio'/>`` or ``<driver name='xen'/>`` in a domain's
status
+ XML, or more rarely in config, but those specific values are
+ essentially ignored.)
+
``readonly``
- Indicates that the device is readonly, only supported by SCSI host device
- now. :since:`Since 1.0.6 (QEMU and KVM only)`
+ Indicates that the device is readonly, only supported by SCSI host
+ device now. :since:`Since 1.0.6 (QEMU and KVM only)`
``shareable``
- If present, this indicates the device is expected to be shared between
- domains (assuming the hypervisor and OS support this). Only supported by SCSI
- host device. :since:`Since 1.0.6`
+ If present, this indicates the device is expected to be shared
+ between domains (assuming the hypervisor and OS support this). Only
+ supported by SCSI host device. :since:`Since 1.0.6`
Note: Although ``shareable`` was introduced :since:`in 1.0.6` , it did not
work as as expected until :since:`1.2.2` .
diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
index e022783816..2ad7232678 100644
--- a/src/conf/device_conf.c
+++ b/src/conf/device_conf.c
@@ -60,13 +60,29 @@ int
virDeviceHostdevPCIDriverInfoParseXML(xmlNodePtr node,
virDeviceHostdevPCIDriverInfo *driver)
{
- if (virXMLPropEnum(node, "name",
+ if (virXMLPropEnum(node, "type",
virDeviceHostdevPCIDriverTypeFromString,
VIR_XML_PROP_NONZERO,
&driver->type) < 0) {
return -1;
}
+ driver->name = virXMLPropString(node, "name");
+
+ /* translate special case of <driver name='vfio|xen|kvm'/> to
+ * <driver type='vfio|xen|kvm'/> for backward compatibility
+ */
+ if (STREQ_NULLABLE(driver->name, "vfio")) {
+ driver->type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_VFIO;
+ VIR_FREE(driver->name);
+ } else if (STREQ_NULLABLE(driver->name, "xen")) {
+ driver->type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_XEN;
+ VIR_FREE(driver->name);
+ } else if (STREQ_NULLABLE(driver->name, "kvm")) {
+ driver->type = VIR_DEVICE_HOSTDEV_PCI_DRIVER_TYPE_KVM;
+ VIR_FREE(driver->name);
+ }
+
return 0;
}
@@ -88,14 +104,23 @@ virDeviceHostdevPCIDriverInfoFormat(virBuffer *buf,
return -1;
}
- virBufferAsprintf(&driverAttrBuf, " name='%s'",
driverType);
+ virBufferAsprintf(&driverAttrBuf, " type='%s'",
driverType);
}
+ virBufferEscapeString(&driverAttrBuf, " name='%s'",
driver->name);
+
virXMLFormatElement(buf, "driver", &driverAttrBuf, NULL);
return 0;
}
+void
+virDeviceHostdevPCIDriverInfoClear(virDeviceHostdevPCIDriverInfo *driver)
+{
+ VIR_FREE(driver->name);
+}
+
+
static int
virZPCIDeviceAddressParseXML(xmlNodePtr node,
virPCIDeviceAddress *addr)
diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index 9f4b9f5375..cccc60cb29 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -46,6 +46,7 @@ VIR_ENUM_DECL(virDeviceHostdevPCIDriver);
struct _virDeviceHostdevPCIDriverInfo {
virDeviceHostdevPCIDriverType type;
+ char *name;
};
typedef enum {
@@ -192,6 +193,9 @@ int virDeviceHostdevPCIDriverInfoParseXML(xmlNodePtr node,
int virDeviceHostdevPCIDriverInfoFormat(virBuffer *buf,
const virDeviceHostdevPCIDriverInfo *driver);
+void virDeviceHostdevPCIDriverInfoPostParse(virDeviceHostdevPCIDriverInfo *driver);
+void virDeviceHostdevPCIDriverInfoClear(virDeviceHostdevPCIDriverInfo *driver);
+
void virDomainDeviceInfoClear(virDomainDeviceInfo *info);
void virDomainDeviceInfoFree(virDomainDeviceInfo *info);
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 04d9de7f32..3b11b927b5 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -2635,6 +2635,7 @@ virDomainHostdevDefClear(virDomainHostdevDef *def)
VIR_FREE(def->source.subsys.u.scsi_host.wwpn);
break;
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI:
+ virDeviceHostdevPCIDriverInfoClear(&def->source.subsys.u.pci.driver);
g_clear_pointer(&def->source.subsys.u.pci.origstates, virBitmapFree);
break;
case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_USB:
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index 2d78d588aa..c8ced95af6 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -229,6 +229,8 @@ virNetworkForwardDefClear(virNetworkForwardDef *def)
{
size_t i;
+ virDeviceHostdevPCIDriverInfoClear(&def->driver);
+
for (i = 0; i < def->npfs && def->pfs; i++)
virNetworkForwardPfDefClear(&def->pfs[i]);
VIR_FREE(def->pfs);
diff --git a/src/conf/schemas/basictypes.rng b/src/conf/schemas/basictypes.rng
index 8d5f4475ca..46e8a493f7 100644
--- a/src/conf/schemas/basictypes.rng
+++ b/src/conf/schemas/basictypes.rng
@@ -658,13 +658,20 @@
<define name="hostdevDriver">
<element name="driver">
- <attribute name="name">
- <choice>
- <value>kvm</value>
- <value>vfio</value>
- <value>xen</value>
- </choice>
- </attribute>
+ <optional>
+ <attribute name="type">
+ <choice>
+ <value>kvm</value>
+ <value>vfio</value>
+ <value>xen</value>
+ </choice>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="name">
+ <ref name="genericName"/>
+ </attribute>
+ </optional>
<empty/>
</element>
</define>
diff --git a/src/conf/virnetworkportdef.c b/src/conf/virnetworkportdef.c
index 49d00b2ea6..64db63ae66 100644
--- a/src/conf/virnetworkportdef.c
+++ b/src/conf/virnetworkportdef.c
@@ -64,6 +64,7 @@ virNetworkPortDefFree(virNetworkPortDef *def)
break;
case VIR_NETWORK_PORT_PLUG_TYPE_HOSTDEV_PCI:
+ virDeviceHostdevPCIDriverInfoClear(&def->plug.hostdevpci.driver);
break;
case VIR_NETWORK_PORT_PLUG_TYPE_LAST:
diff --git a/tests/networkxml2xmlin/hostdev-pf-old.xml
b/tests/networkxml2xmlin/hostdev-pf-old.xml
new file mode 100644
index 0000000000..5b8f59858c
--- /dev/null
+++ b/tests/networkxml2xmlin/hostdev-pf-old.xml
@@ -0,0 +1,8 @@
+<network>
+ <name>hostdev</name>
+ <uuid>81ff0d90-c91e-6742-64da-4a736edb9a9b</uuid>
+ <forward mode='hostdev' managed='yes'>
+ <driver name='vfio'/>
+ <pf dev='eth2'/>
+ </forward>
+</network>
diff --git a/tests/networkxml2xmlin/hostdev-pf.xml
b/tests/networkxml2xmlin/hostdev-pf.xml
index 5b8f59858c..72a3049800 100644
--- a/tests/networkxml2xmlin/hostdev-pf.xml
+++ b/tests/networkxml2xmlin/hostdev-pf.xml
@@ -2,7 +2,7 @@
<name>hostdev</name>
<uuid>81ff0d90-c91e-6742-64da-4a736edb9a9b</uuid>
<forward mode='hostdev' managed='yes'>
- <driver name='vfio'/>
+ <driver type='vfio'/>
<pf dev='eth2'/>
</forward>
</network>
diff --git a/tests/networkxml2xmlout/hostdev-pf-old.xml
b/tests/networkxml2xmlout/hostdev-pf-old.xml
new file mode 100644
index 0000000000..72a3049800
--- /dev/null
+++ b/tests/networkxml2xmlout/hostdev-pf-old.xml
@@ -0,0 +1,8 @@
+<network>
+ <name>hostdev</name>
+ <uuid>81ff0d90-c91e-6742-64da-4a736edb9a9b</uuid>
+ <forward mode='hostdev' managed='yes'>
+ <driver type='vfio'/>
+ <pf dev='eth2'/>
+ </forward>
+</network>
diff --git a/tests/networkxml2xmlout/hostdev-pf.xml
b/tests/networkxml2xmlout/hostdev-pf.xml
index 5b8f59858c..72a3049800 100644
--- a/tests/networkxml2xmlout/hostdev-pf.xml
+++ b/tests/networkxml2xmlout/hostdev-pf.xml
@@ -2,7 +2,7 @@
<name>hostdev</name>
<uuid>81ff0d90-c91e-6742-64da-4a736edb9a9b</uuid>
<forward mode='hostdev' managed='yes'>
- <driver name='vfio'/>
+ <driver type='vfio'/>
<pf dev='eth2'/>
</forward>
</network>
diff --git a/tests/networkxml2xmltest.c b/tests/networkxml2xmltest.c
index b0814c7529..928f28b579 100644
--- a/tests/networkxml2xmltest.c
+++ b/tests/networkxml2xmltest.c
@@ -146,6 +146,12 @@ mymain(void)
DO_TEST_FLAGS("passthrough-pf", VIR_NETWORK_XML_INACTIVE);
DO_TEST("hostdev");
DO_TEST_FLAGS("hostdev-pf", VIR_NETWORK_XML_INACTIVE);
+
+ /* libvirt pre-9.9.0 used "name='vfio'" which should be
+ * automatically translated to "type='vfio'" by new parser
+ */
+ DO_TEST_FLAGS("hostdev-pf-old", VIR_NETWORK_XML_INACTIVE);
+
DO_TEST("passthrough-address-crash");
DO_TEST("nat-network-explicit-flood");
DO_TEST("host-bridge-no-flood");
diff --git a/tests/qemuhotplugtestdevices/qemuhotplug-hostdev-pci.xml
b/tests/qemuhotplugtestdevices/qemuhotplug-hostdev-pci.xml
index 6f7c99c943..0d6dec9d26 100644
--- a/tests/qemuhotplugtestdevices/qemuhotplug-hostdev-pci.xml
+++ b/tests/qemuhotplugtestdevices/qemuhotplug-hostdev-pci.xml
@@ -1,5 +1,4 @@
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x2'/>
</source>
diff --git a/tests/qemuhotplugtestdomains/qemuhotplug-base-live+hostdev-pci.xml
b/tests/qemuhotplugtestdomains/qemuhotplug-base-live+hostdev-pci.xml
index e49e21c53e..b14f184044 100644
--- a/tests/qemuhotplugtestdomains/qemuhotplug-base-live+hostdev-pci.xml
+++ b/tests/qemuhotplugtestdomains/qemuhotplug-base-live+hostdev-pci.xml
@@ -49,7 +49,7 @@
</input>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
+ <driver type='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x2'/>
</source>
diff --git a/tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+hostdev-pci.xml
b/tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+hostdev-pci.xml
index 13d10e57aa..02b66a3590 100644
--- a/tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+hostdev-pci.xml
+++ b/tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+hostdev-pci.xml
@@ -41,7 +41,7 @@
</input>
<audio id='1' type='none'/>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
+ <driver type='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x2'/>
</source>
diff --git a/tests/qemustatusxml2xmldata/modern-in.xml
b/tests/qemustatusxml2xmldata/modern-in.xml
index 67e0aa4952..299046331e 100644
--- a/tests/qemustatusxml2xmldata/modern-in.xml
+++ b/tests/qemustatusxml2xmldata/modern-in.xml
@@ -502,7 +502,7 @@
<address type='drive' controller='0' bus='0'
target='2' unit='4'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
- <driver name='vfio'/>
+ <driver type='vfio'/>
<source>
<address domain='0x0005' bus='0x90' slot='0x01'
function='0x2'/>
<origstates>
diff --git a/tests/qemuxml2argvdata/hostdev-vfio.x86_64-latest.args
b/tests/qemuxml2argvdata/hostdev-vfio.x86_64-latest.args
index c1f9258844..8529cde269 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio.x86_64-latest.args
+++ b/tests/qemuxml2argvdata/hostdev-vfio.x86_64-latest.args
@@ -32,6 +32,9 @@ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest2/.config \
-device
'{"driver":"ide-hd","bus":"ide.0","unit":0,"drive":"libvirt-1-format","id":"ide0-0-0","bootindex":1}'
\
-audiodev
'{"id":"audio1","driver":"none"}' \
-device
'{"driver":"vfio-pci","host":"0000:06:12.1","id":"hostdev0","bus":"pci.0","addr":"0x2"}'
\
--device
'{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.0","addr":"0x3"}'
\
+-device
'{"driver":"vfio-pci","host":"0000:06:12.2","id":"hostdev1","bus":"pci.0","addr":"0x3"}'
\
+-device
'{"driver":"vfio-pci","host":"0000:06:12.3","id":"hostdev2","bus":"pci.0","addr":"0x4"}'
\
+-device
'{"driver":"vfio-pci","host":"0000:06:12.4","id":"hostdev3","bus":"pci.0","addr":"0x5"}'
\
+-device
'{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.0","addr":"0x6"}'
\
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
diff --git a/tests/qemuxml2argvdata/hostdev-vfio.xml
b/tests/qemuxml2argvdata/hostdev-vfio.xml
index a03870f6e0..609714ab06 100644
--- a/tests/qemuxml2argvdata/hostdev-vfio.xml
+++ b/tests/qemuxml2argvdata/hostdev-vfio.xml
@@ -29,6 +29,24 @@
<address domain='0x0000' bus='0x06' slot='0x12'
function='0x1'/>
</source>
</hostdev>
+ <hostdev mode='subsystem' type='pci' managed='yes'>
+ <driver type='vfio'/>
+ <source>
+ <address domain='0x0000' bus='0x06' slot='0x12'
function='0x2'/>
+ </source>
+ </hostdev>
+ <hostdev mode='subsystem' type='pci' managed='yes'>
+ <driver name='vfio'/>
+ <source>
+ <address domain='0x0000' bus='0x06' slot='0x12'
function='0x3'/>
+ </source>
+ </hostdev>
+ <hostdev mode='subsystem' type='pci' managed='yes'>
+ <driver name='vfio-pci-igb'/>
+ <source>
+ <address domain='0x0000' bus='0x06' slot='0x12'
function='0x4'/>
+ </source>
+ </hostdev>
<memballoon model='virtio'/>
</devices>
</domain>
diff --git a/tests/qemuxml2xmloutdata/hostdev-vfio.x86_64-latest.xml
b/tests/qemuxml2xmloutdata/hostdev-vfio.x86_64-latest.xml
index 3915b515f2..bae07de8d2 100644
--- a/tests/qemuxml2xmloutdata/hostdev-vfio.x86_64-latest.xml
+++ b/tests/qemuxml2xmloutdata/hostdev-vfio.x86_64-latest.xml
@@ -39,8 +39,29 @@
</source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x02' function='0x0'/>
</hostdev>
- <memballoon model='virtio'>
+ <hostdev mode='subsystem' type='pci' managed='yes'>
+ <driver type='vfio'/>
+ <source>
+ <address domain='0x0000' bus='0x06' slot='0x12'
function='0x2'/>
+ </source>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
+ </hostdev>
+ <hostdev mode='subsystem' type='pci' managed='yes'>
+ <driver type='vfio'/>
+ <source>
+ <address domain='0x0000' bus='0x06' slot='0x12'
function='0x3'/>
+ </source>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x04' function='0x0'/>
+ </hostdev>
+ <hostdev mode='subsystem' type='pci' managed='yes'>
+ <driver name='vfio-pci-igb'/>
+ <source>
+ <address domain='0x0000' bus='0x06' slot='0x12'
function='0x4'/>
+ </source>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x05' function='0x0'/>
+ </hostdev>
+ <memballoon model='virtio'>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x06' function='0x0'/>
</memballoon>
</devices>
</domain>
diff --git a/tests/virnetworkportxml2xmldata/plug-hostdev-pci-unmanaged.xml
b/tests/virnetworkportxml2xmldata/plug-hostdev-pci-unmanaged.xml
index da5f568031..5d9f7cae73 100644
--- a/tests/virnetworkportxml2xmldata/plug-hostdev-pci-unmanaged.xml
+++ b/tests/virnetworkportxml2xmldata/plug-hostdev-pci-unmanaged.xml
@@ -6,7 +6,7 @@
</owner>
<mac address='52:54:00:7b:35:93'/>
<plug type='hostdev-pci' managed='no'>
- <driver name='vfio'/>
+ <driver type='vfio'/>
<address domain='0x0001' bus='0x02' slot='0x03'
function='0x4'/>
</plug>
</networkport>
diff --git a/tests/virnetworkportxml2xmldata/plug-hostdev-pci.xml
b/tests/virnetworkportxml2xmldata/plug-hostdev-pci.xml
index cc4419f3fd..d216fc916e 100644
--- a/tests/virnetworkportxml2xmldata/plug-hostdev-pci.xml
+++ b/tests/virnetworkportxml2xmldata/plug-hostdev-pci.xml
@@ -6,7 +6,7 @@
</owner>
<mac address='52:54:00:7b:35:93'/>
<plug type='hostdev-pci' managed='yes'>
- <driver name='vfio'/>
+ <driver type='vfio'/>
<address domain='0x0001' bus='0x02' slot='0x03'
function='0x4'/>
</plug>
</networkport>
--
2.41.0
8:58 a.m.
New subject: [libvirt PATCH v2 12/15] conf: support manually specifying VFIO
variant driver in <hostdev> XML
On Mon, Nov 06, 2023 at 02:38:57 -0500, Laine Stump wrote:
This patch makes it possible to manually specify which VFIO variant
driver to use for PCI hostdev device assignment, so that, e.g. you
could force use of the generic vfio-pci driver with
<driver name='vfio-pci'/>
when libvirt would have normally (after applying a subsequent patch)
found a "better match" for a device in the active kernel's
modules.alias file. (The main use of this manual override would be to
work around a bug in a new VFIO variant driver by temporarily not
using that driver).
This sounds like a simple addition to XML parsing/formatting, but of
course it's messier than that, since the attribute we want to use was
previously used in config for a now non-existent purpose (choosing a
type of device assignment that was removed from the kernel nearly a
decade ago), and continues to be used *internal to the C code*.
Background:
Beginning when VFIO device assignment support was added to <hostdev>
or <interface type='hostdev'/>) in libvirt's QEMU driver, it was
possible to specify which device assignment backend to use with
"<driver name='vfio|kvm'/>". This was only useful for a couple
of
years in the early 2010's when VFIO device assignment was newly
introduced, but "legacy KVM" device assignment was still possible (in
reality "<driver name='blah'/>" was only intended to be used (1)
in
the *very* early days of VFIO when "kvm" was still the default, or (2)
when the host kernel was too old to have VFIO support (meaning it was
e.g. pre-RHEL7) or (3) some bug was encountered with the then-new VFIO
code that could have been avoided by switching back to the older style
of device assignment (I don't recall anyone ever needing to set it for
this reason, but that is one of the main reasons we added the knob).
Later, when the libxl (Xen) driver in libvirt began supporting "device
passthrough" with <hostdev>, they added <driver name='xen'/> to
indicate that mode of operation. But in practice this was also never
necessary in any config, since Xen only supports one type of device
assignment, and so the attribute was anyway set in the C object by the
libxl driver code prior to calling any hypervisor-common code
(i.e. the stuff in hypervisor/hostdev.c and util/virpci.c) that needs
to know which type of device assignment is being used - setting it in
the XML config was superfluous (kind of like me saying "I am now
describing this patch in a human language", ref: Perd Hapley on "Parks
and Recreation").
So the setting was available in the XML, but never needed to be set by
the user. Because it was automatically set in the C code though,
sometimes libvirt-generated XML would contain the option even though
the user hadn't included it in the original input XML (e.g. the libxl
driver sets it in the PostParse, so all saved configs with a PCI
<hostdev> device will have <driver name='xen'/>; also status XML
from
the QEMU and libxl drivers will contain <driver name='vfio|xen'/> - in
both cases completely unnecessary and redundant information).
When adding support for specifying a variant driver for VFIO device
assignment, from the beginning I have wanted to use <driver
name='blah'/> to force a specific variant driver (e.g. <driver
name='mlx5_vfio_pci'/>), with the assumption that the name attribute
could be easily repurposed because it had been *completely* unused for
so long. What I discovered though, was that 1) the field in the C
object corresponding to driver name was an enum value rather than a
string (so parser and formatter need to be changed, not just the
driver code looking at a string in the C object), and 2) even though
the XML attribute was effectively unused (except in some output), the
field in the C object was *always* being set internally as a way for
the hypervisor driver code to inform the hypervisor-common hostdev
manager (in src/hypervisor) which method of device assignment to
use. So re-use wasn't as simple as I'd wished.
However.
What I have hit upon that permits us to use
<driver name='mlx5_vfio_pci'/> is to do the following:
1) rename the existing driver name attribute to driver *type* - this
will now be the enum that is set internally by the hypervisor
driver prior to calling the hostdev manager (and also is what will
show up in status XML; the libxl driver was modified in a previous
patch so that the setting isn't done until domain runtime (rather
than during PostParse), so it will no longer show up in
regurgitated libxml config)
2) add a new attribute with the now-newly-unused name "name" - this
will be a string that can be used to communicate a specific host
kernel driver to the hostdev manager.
3) In the parsing code for <driver>, if <driver
name='vfio|xen|kvm'/>
is encountered, set the driver *type* to the appropriate enum
instead, and clear our the name string. (since the four places
that use the hostdev <driver> element now all call a common parser
function, this check is only needed in a single place)
I could alternately just leave "name" as-is, and create a new
attribute with a never-before-used name within driver. I suppose
instead of "type" and "name", we could instead have "name and
"model"
(where "model" would be the string that could be set to
"mlx5_vfio_pci"). I just prefer type/name to name/model, and think
it's been long enough since <driver name='blah'/> has had a useful
purpose (and the fixup for backward compatibility is limited to a few
lines in one function) that this change is safe.
I'm not entirely sold on the reusing of the 'name' attribute and this
paragraph seems to confirm that it's just for optics.
I'm a bit worried that some tool may be checking the output here however
useless it is and that tool might then need changing just because we
wanted "better looking" attribute names.
(another alternate would be to add an extra parameter to the C API
that calls into the hostdev manager rather than keeping/adding the
publicly visible "type" attribute, but it seems at least possible that
sometime in the future another alternate "type" of device assignment
could be introduced for either Xen or QEMU, and we would then need to
add back the XML attribute anyway)
I'd be fine with doing it one of the other ways, but decided to post
this way first, since it's the one that I find the most aesthetically
pleasing :-)
Okay this paragraph is a bit too much of discussion for a commit
message. Please put stuff like this under the lines or as a RFC
question.
Note that a few test cases have been modified - places where an
existing "name='vfio'" was changed to "type='vfio'"
were in in status
XML or only the *output* XML for a test (except the case of the
virnetworkportxml2xmltest, which doesn't have a separate directory for
the XML result; fortunately the converged parsing of <driver> between
domain/network/networkport means that the test cases for network and
domain XML are already testing the same code that would convert "name"
to "type" in thte networkport XML)
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
The code looks okay but I'm not a fan of the rename for cosmetical
reasons. Especially if we fiddle with the value in the field with
original name and display it back to the user/management sw.
12:25 a.m.
New subject: [libvirt PATCH v2 12/15] conf: support manually specifying VFIO
variant driver in <hostdev> XML
On 11/28/23 9:58 AM, Peter Krempa wrote:
On Mon, Nov 06, 2023 at 02:38:57 -0500, Laine Stump wrote:
> This patch makes it possible to manually specify which VFIO variant
> driver to use for PCI hostdev device assignment, so that, e.g. you
> could force use of the generic vfio-pci driver with
>
> <driver name='vfio-pci'/>
>
> when libvirt would have normally (after applying a subsequent patch)
> found a "better match" for a device in the active kernel's
> modules.alias file. (The main use of this manual override would be to
> work around a bug in a new VFIO variant driver by temporarily not
> using that driver).
>
> This sounds like a simple addition to XML parsing/formatting, but of
> course it's messier than that, since the attribute we want to use was
> previously used in config for a now non-existent purpose (choosing a
> type of device assignment that was removed from the kernel nearly a
> decade ago), and continues to be used *internal to the C code*.
>
> Background:
>
> Beginning when VFIO device assignment support was added to <hostdev>
> or <interface type='hostdev'/>) in libvirt's QEMU driver, it was
> possible to specify which device assignment backend to use with
> "<driver name='vfio|kvm'/>". This was only useful for a
couple of
> years in the early 2010's when VFIO device assignment was newly
> introduced, but "legacy KVM" device assignment was still possible (in
> reality "<driver name='blah'/>" was only intended to be used
(1) in
> the *very* early days of VFIO when "kvm" was still the default, or (2)
> when the host kernel was too old to have VFIO support (meaning it was
> e.g. pre-RHEL7) or (3) some bug was encountered with the then-new VFIO
> code that could have been avoided by switching back to the older style
> of device assignment (I don't recall anyone ever needing to set it for
> this reason, but that is one of the main reasons we added the knob).
>
> Later, when the libxl (Xen) driver in libvirt began supporting "device
> passthrough" with <hostdev>, they added <driver name='xen'/>
to
> indicate that mode of operation. But in practice this was also never
> necessary in any config, since Xen only supports one type of device
> assignment, and so the attribute was anyway set in the C object by the
> libxl driver code prior to calling any hypervisor-common code
> (i.e. the stuff in hypervisor/hostdev.c and util/virpci.c) that needs
> to know which type of device assignment is being used - setting it in
> the XML config was superfluous (kind of like me saying "I am now
> describing this patch in a human language", ref: Perd Hapley on "Parks
> and Recreation").
>
> So the setting was available in the XML, but never needed to be set by
> the user. Because it was automatically set in the C code though,
> sometimes libvirt-generated XML would contain the option even though
> the user hadn't included it in the original input XML (e.g. the libxl
> driver sets it in the PostParse, so all saved configs with a PCI
> <hostdev> device will have <driver name='xen'/>; also status XML
from
> the QEMU and libxl drivers will contain <driver name='vfio|xen'/> - in
> both cases completely unnecessary and redundant information).
>
> When adding support for specifying a variant driver for VFIO device
> assignment, from the beginning I have wanted to use <driver
> name='blah'/> to force a specific variant driver (e.g. <driver
> name='mlx5_vfio_pci'/>), with the assumption that the name attribute
> could be easily repurposed because it had been *completely* unused for
> so long. What I discovered though, was that 1) the field in the C
> object corresponding to driver name was an enum value rather than a
> string (so parser and formatter need to be changed, not just the
> driver code looking at a string in the C object), and 2) even though
> the XML attribute was effectively unused (except in some output), the
> field in the C object was *always* being set internally as a way for
> the hypervisor driver code to inform the hypervisor-common hostdev
> manager (in src/hypervisor) which method of device assignment to
> use. So re-use wasn't as simple as I'd wished.
>
> However.
>
> What I have hit upon that permits us to use
> <driver name='mlx5_vfio_pci'/> is to do the following:
>
> 1) rename the existing driver name attribute to driver *type* - this
> will now be the enum that is set internally by the hypervisor
> driver prior to calling the hostdev manager (and also is what will
> show up in status XML; the libxl driver was modified in a previous
> patch so that the setting isn't done until domain runtime (rather
> than during PostParse), so it will no longer show up in
> regurgitated libxml config)
>
> 2) add a new attribute with the now-newly-unused name "name" - this
> will be a string that can be used to communicate a specific host
> kernel driver to the hostdev manager.
>
> 3) In the parsing code for <driver>, if <driver
name='vfio|xen|kvm'/>
> is encountered, set the driver *type* to the appropriate enum
> instead, and clear our the name string. (since the four places
> that use the hostdev <driver> element now all call a common parser
> function, this check is only needed in a single place)
>
> I could alternately just leave "name" as-is, and create a new
> attribute with a never-before-used name within driver. I suppose
> instead of "type" and "name", we could instead have "name
and "model"
> (where "model" would be the string that could be set to
> "mlx5_vfio_pci"). I just prefer type/name to name/model, and think
> it's been long enough since <driver name='blah'/> has had a useful
> purpose (and the fixup for backward compatibility is limited to a few
> lines in one function) that this change is safe.
I'm not entirely sold on the reusing of the 'name' attribute and this
paragraph seems to confirm that it's just for optics.
I'm a bit worried that some tool may be checking the output here however
useless it is and that tool might then need changing just because we
wanted "better looking" attribute names.
Sigh. Yeah, you're probably right.
Okay, so how about keeping <driver name='vfio|xen'> (but still
minimizing its auto-generation as much as possible), and using
<driver model='blah'/> when we want to specify a particular driver?
> (another alternate would be to add an extra parameter to the C API
> that calls into the hostdev manager rather than keeping/adding the
> publicly visible "type" attribute, but it seems at least possible that
> sometime in the future another alternate "type" of device assignment
> could be introduced for either Xen or QEMU, and we would then need to
> add back the XML attribute anyway)
>
> I'd be fine with doing it one of the other ways, but decided to post
> this way first, since it's the one that I find the most aesthetically
> pleasing :-)
Okay this paragraph is a bit too much of discussion for a commit
message. Please put stuff like this under the lines or as a RFC
question.
Yeah, I meant to do that but forgot.
> Note that a few test cases have been modified - places where an
> existing "name='vfio'" was changed to
"type='vfio'" were in in status
> XML or only the *output* XML for a test (except the case of the
> virnetworkportxml2xmltest, which doesn't have a separate directory for
> the XML result; fortunately the converged parsing of <driver> between
> domain/network/networkport means that the test cases for network and
> domain XML are already testing the same code that would convert "name"
> to "type" in thte networkport XML)
>
> Signed-off-by: Laine Stump <laine(a)redhat.com>
> ---
The code looks okay but I'm not a fan of the rename for cosmetical
reasons. Especially if we fiddle with the value in the field with
original name and display it back to the user/management sw.
I'll redo everything to use <driver model> and try to get it posted in
the next day or two. If you or anyone else thinks of a better name let
me know.
3 a.m.
New subject: [libvirt PATCH v2 12/15] conf: support manually specifying VFIO
variant driver in <hostdev> XML
On Mon, Dec 18, 2023 at 01:25:02 -0500, Laine Stump wrote:
On 11/28/23 9:58 AM, Peter Krempa wrote:
> On Mon, Nov 06, 2023 at 02:38:57 -0500, Laine Stump wrote:
> > This patch makes it possible to manually specify which VFIO variant
> > driver to use for PCI hostdev device assignment, so that, e.g. you
> > could force use of the generic vfio-pci driver with
> >
> > <driver name='vfio-pci'/>
> >
> > when libvirt would have normally (after applying a subsequent patch)
> > found a "better match" for a device in the active kernel's
> > modules.alias file. (The main use of this manual override would be to
> > work around a bug in a new VFIO variant driver by temporarily not
> > using that driver).
> >
> > This sounds like a simple addition to XML parsing/formatting, but of
> > course it's messier than that, since the attribute we want to use was
> > previously used in config for a now non-existent purpose (choosing a
> > type of device assignment that was removed from the kernel nearly a
> > decade ago), and continues to be used *internal to the C code*.
> >
> > Background:
> >
> > Beginning when VFIO device assignment support was added to <hostdev>
> > or <interface type='hostdev'/>) in libvirt's QEMU driver, it
was
> > possible to specify which device assignment backend to use with
> > "<driver name='vfio|kvm'/>". This was only useful for a
couple of
> > years in the early 2010's when VFIO device assignment was newly
> > introduced, but "legacy KVM" device assignment was still possible
(in
> > reality "<driver name='blah'/>" was only intended to be
used (1) in
> > the *very* early days of VFIO when "kvm" was still the default, or
(2)
> > when the host kernel was too old to have VFIO support (meaning it was
> > e.g. pre-RHEL7) or (3) some bug was encountered with the then-new VFIO
> > code that could have been avoided by switching back to the older style
> > of device assignment (I don't recall anyone ever needing to set it for
> > this reason, but that is one of the main reasons we added the knob).
> >
> > Later, when the libxl (Xen) driver in libvirt began supporting "device
> > passthrough" with <hostdev>, they added <driver
name='xen'/> to
> > indicate that mode of operation. But in practice this was also never
> > necessary in any config, since Xen only supports one type of device
> > assignment, and so the attribute was anyway set in the C object by the
> > libxl driver code prior to calling any hypervisor-common code
> > (i.e. the stuff in hypervisor/hostdev.c and util/virpci.c) that needs
> > to know which type of device assignment is being used - setting it in
> > the XML config was superfluous (kind of like me saying "I am now
> > describing this patch in a human language", ref: Perd Hapley on
"Parks
> > and Recreation").
> >
> > So the setting was available in the XML, but never needed to be set by
> > the user. Because it was automatically set in the C code though,
> > sometimes libvirt-generated XML would contain the option even though
> > the user hadn't included it in the original input XML (e.g. the libxl
> > driver sets it in the PostParse, so all saved configs with a PCI
> > <hostdev> device will have <driver name='xen'/>; also
status XML from
> > the QEMU and libxl drivers will contain <driver name='vfio|xen'/>
- in
> > both cases completely unnecessary and redundant information).
> >
> > When adding support for specifying a variant driver for VFIO device
> > assignment, from the beginning I have wanted to use <driver
> > name='blah'/> to force a specific variant driver (e.g. <driver
> > name='mlx5_vfio_pci'/>), with the assumption that the name
attribute
> > could be easily repurposed because it had been *completely* unused for
> > so long. What I discovered though, was that 1) the field in the C
> > object corresponding to driver name was an enum value rather than a
> > string (so parser and formatter need to be changed, not just the
> > driver code looking at a string in the C object), and 2) even though
> > the XML attribute was effectively unused (except in some output), the
> > field in the C object was *always* being set internally as a way for
> > the hypervisor driver code to inform the hypervisor-common hostdev
> > manager (in src/hypervisor) which method of device assignment to
> > use. So re-use wasn't as simple as I'd wished.
> >
> > However.
> >
> > What I have hit upon that permits us to use
> > <driver name='mlx5_vfio_pci'/> is to do the following:
> >
> > 1) rename the existing driver name attribute to driver *type* - this
> > will now be the enum that is set internally by the hypervisor
> > driver prior to calling the hostdev manager (and also is what will
> > show up in status XML; the libxl driver was modified in a previous
> > patch so that the setting isn't done until domain runtime (rather
> > than during PostParse), so it will no longer show up in
> > regurgitated libxml config)
> >
> > 2) add a new attribute with the now-newly-unused name "name" - this
> > will be a string that can be used to communicate a specific host
> > kernel driver to the hostdev manager.
> >
> > 3) In the parsing code for <driver>, if <driver
name='vfio|xen|kvm'/>
> > is encountered, set the driver *type* to the appropriate enum
> > instead, and clear our the name string. (since the four places
> > that use the hostdev <driver> element now all call a common parser
> > function, this check is only needed in a single place)
> >
> > I could alternately just leave "name" as-is, and create a new
> > attribute with a never-before-used name within driver. I suppose
> > instead of "type" and "name", we could instead have
"name and "model"
> > (where "model" would be the string that could be set to
> > "mlx5_vfio_pci"). I just prefer type/name to name/model, and think
> > it's been long enough since <driver name='blah'/> has had a
useful
> > purpose (and the fixup for backward compatibility is limited to a few
> > lines in one function) that this change is safe.
>
> I'm not entirely sold on the reusing of the 'name' attribute and this
> paragraph seems to confirm that it's just for optics.
>
> I'm a bit worried that some tool may be checking the output here however
> useless it is and that tool might then need changing just because we
> wanted "better looking" attribute names.
Sigh. Yeah, you're probably right.
Okay, so how about keeping <driver name='vfio|xen'> (but still minimizing
its auto-generation as much as possible), and using
<driver model='blah'/> when we want to specify a particular driver?
That sounds good. The 'name=' attribute should be present in the runtime
XML when it was selected, but based on your previous explanation we
don't need to keep putting it into the config at post-parse time.
If it was specified though, don't remove it.
> > (another alternate would be to add an extra parameter to
the C API
> > that calls into the hostdev manager rather than keeping/adding the
> > publicly visible "type" attribute, but it seems at least possible
that
> > sometime in the future another alternate "type" of device assignment
> > could be introduced for either Xen or QEMU, and we would then need to
> > add back the XML attribute anyway)
> >
> > I'd be fine with doing it one of the other ways, but decided to post
> > this way first, since it's the one that I find the most aesthetically
> > pleasing :-)
>
> Okay this paragraph is a bit too much of discussion for a commit
> message. Please put stuff like this under the lines or as a RFC
> question.
Yeah, I meant to do that but forgot.
>
>
> > Note that a few test cases have been modified - places where an
> > existing "name='vfio'" was changed to
"type='vfio'" were in in status
> > XML or only the *output* XML for a test (except the case of the
> > virnetworkportxml2xmltest, which doesn't have a separate directory for
> > the XML result; fortunately the converged parsing of <driver> between
> > domain/network/networkport means that the test cases for network and
> > domain XML are already testing the same code that would convert
"name"
> > to "type" in thte networkport XML)
> >
> > Signed-off-by: Laine Stump <laine(a)redhat.com>
> > ---
>
> The code looks okay but I'm not a fan of the rename for cosmetical
> reasons. Especially if we fiddle with the value in the field with
> original name and display it back to the user/management sw.
I'll redo everything to use <driver model> and try to get it posted in the
next day or two. If you or anyone else thinks of a better name let me know.
1:38 a.m.
New subject: [libvirt PATCH v2 13/15] util: new function virStringSkipToSpace()
Add a surprisingly missing simple function to the arsenal.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/libvirt_private.syms | 1 +
src/util/virstring.c | 17 +++++++++++++++++
src/util/virstring.h | 1 +
3 files changed, 19 insertions(+)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index a943a79e01..3e8eded81e 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -3409,6 +3409,7 @@ virSkipSpaces;
virSkipSpacesAndBackslash;
virSkipSpacesBackwards;
virSkipToDigit;
+virSkipToSpace;
virStrcpy;
virStringBufferIsPrintable;
virStringFilterChars;
diff --git a/src/util/virstring.c b/src/util/virstring.c
index 6b728ff047..4a732de5dc 100644
--- a/src/util/virstring.c
+++ b/src/util/virstring.c
@@ -441,6 +441,23 @@ virSkipToDigit(const char **str)
}
+/**
+ * virSkipToSApace:
+ * @str: pointer to the char pointer used
+ *
+ * Skip over any character that is not whitespace
+ */
+void
+virSkipToSpace(const char **str)
+{
+ const char *cur = *str;
+
+ while (*cur && !g_ascii_isspace(*cur))
+ cur++;
+ *str = cur;
+}
+
+
/**
* virTrimSpaces:
* @str: string to modify to remove all trailing spaces
diff --git a/src/util/virstring.h b/src/util/virstring.h
index 16dcce98f4..9fd8be44cf 100644
--- a/src/util/virstring.h
+++ b/src/util/virstring.h
@@ -74,6 +74,7 @@ int virDoubleToStr(char **strp, double number)
void virSkipSpaces(const char **str) ATTRIBUTE_NONNULL(1);
void virSkipSpacesAndBackslash(const char **str) ATTRIBUTE_NONNULL(1);
void virSkipToDigit(const char **str) ATTRIBUTE_NONNULL(1);
+void virSkipToSpace(const char **str) ATTRIBUTE_NONNULL(1);
void virTrimSpaces(char *str, char **endp) ATTRIBUTE_NONNULL(1);
void virSkipSpacesBackwards(const char *str, char **endp)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
--
2.41.0
9:42 a.m.
New subject: [libvirt PATCH v2 13/15] util: new function
virStringSkipToSpace()
On Mon, Nov 06, 2023 at 02:38:58 -0500, Laine Stump wrote:
Add a surprisingly missing simple function to the arsenal.
I'd almost prefer to have this simply inlined into the only user.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/libvirt_private.syms | 1 +
src/util/virstring.c | 17 +++++++++++++++++
src/util/virstring.h | 1 +
3 files changed, 19 insertions(+)
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
1:38 a.m.
New subject: [libvirt PATCH v2 14/15] tests: mock virPCIDevice(BindTo|UnbindFrom)Stub with nop functions
Only in qemuhotplug test, in order to not fail when running the
test on macOS.
This is a temporary measure until I decice how best to make a mock
environment that allows virPCIDeviceFindBestVariant() to succeed on
non-Linux platforms (which is a bit nonsensical, since none of that
code will ever run on non-Linux anyway).
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/libvirt_private.syms | 2 ++
src/util/virpci.c | 4 ++--
src/util/virpci.h | 3 +++
tests/qemuhotplugmock.c | 15 +++++++++++++++
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 3e8eded81e..0e8353cc22 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -3072,6 +3072,7 @@ virPCIDeviceAddressIOMMUGroupIterate;
virPCIDeviceAddressIsEmpty;
virPCIDeviceAddressIsValid;
virPCIDeviceAddressParse;
+virPCIDeviceBindToStub;
virPCIDeviceCopy;
virPCIDeviceDetach;
virPCIDeviceExists;
@@ -3120,6 +3121,7 @@ virPCIDeviceSetStubDriverType;
virPCIDeviceSetUnbindFromStub;
virPCIDeviceSetUsedBy;
virPCIDeviceUnbind;
+virPCIDeviceUnbindFromStub;
virPCIEDeviceInfoFree;
virPCIELinkSpeedTypeFromString;
virPCIELinkSpeedTypeToString;
diff --git a/src/util/virpci.c b/src/util/virpci.c
index dfc97dc981..885958eb99 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -1406,7 +1406,7 @@ virPCIDeviceBindWithDriverOverride(virPCIDevice *dev,
return 0;
}
-static int
+int
virPCIDeviceUnbindFromStub(virPCIDevice *dev)
{
if (!dev->unbind_from_stub) {
@@ -1417,7 +1417,7 @@ virPCIDeviceUnbindFromStub(virPCIDevice *dev)
return virPCIDeviceBindWithDriverOverride(dev, "\n");
}
-static int
+int
virPCIDeviceBindToStub(virPCIDevice *dev)
{
g_autofree char *stubDriverPath = NULL;
diff --git a/src/util/virpci.h b/src/util/virpci.h
index faca6cf6f9..4fbace7f67 100644
--- a/src/util/virpci.h
+++ b/src/util/virpci.h
@@ -131,6 +131,9 @@ int virPCIDeviceReset(virPCIDevice *dev,
virPCIDeviceList *activeDevs,
virPCIDeviceList *inactiveDevs);
+int virPCIDeviceUnbindFromStub(virPCIDevice *dev);
+int virPCIDeviceBindToStub(virPCIDevice *dev);
+
void virPCIDeviceSetManaged(virPCIDevice *dev,
bool managed);
bool virPCIDeviceGetManaged(virPCIDevice *dev);
diff --git a/tests/qemuhotplugmock.c b/tests/qemuhotplugmock.c
index dd7e2c67e0..e578046e0d 100644
--- a/tests/qemuhotplugmock.c
+++ b/tests/qemuhotplugmock.c
@@ -25,6 +25,7 @@
#include "conf/domain_conf.h"
#include "virdevmapper.h"
#include "virmock.h"
+#include "virpci.h"
#include <fcntl.h>
#define LIBVIRT_QEMU_MONITOR_PRIV_H_ALLOW
@@ -81,6 +82,20 @@ virFileExists(const char *path)
}
+int
+virPCIDeviceBindToStub(virPCIDevice *dev G_GNUC_UNUSED)
+{
+ return 0;
+}
+
+
+int
+virPCIDeviceUnbindFromStub(virPCIDevice *dev G_GNUC_UNUSED)
+{
+ return 0;
+}
+
+
int
qemuProcessStartManagedPRDaemon(virDomainObj *vm G_GNUC_UNUSED)
{
--
2.41.0
9:03 a.m.
New subject: [libvirt PATCH v2 14/15] tests: mock
virPCIDevice(BindTo|UnbindFrom)Stub with nop functions
On Mon, Nov 06, 2023 at 02:38:59 -0500, Laine Stump wrote:
Only in qemuhotplug test, in order to not fail when running the
test on macOS.
This is a temporary measure until I decice how best to make a mock
environment that allows virPCIDeviceFindBestVariant() to succeed on
non-Linux platforms (which is a bit nonsensical, since none of that
code will ever run on non-Linux anyway).
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
[...]
diff --git a/src/util/virpci.h b/src/util/virpci.h
index faca6cf6f9..4fbace7f67 100644
--- a/src/util/virpci.h
+++ b/src/util/virpci.h
@@ -131,6 +131,9 @@ int virPCIDeviceReset(virPCIDevice *dev,
virPCIDeviceList *activeDevs,
virPCIDeviceList *inactiveDevs);
+int virPCIDeviceUnbindFromStub(virPCIDevice *dev);
+int virPCIDeviceBindToStub(virPCIDevice *dev);
+
You need to use G_NO_INLINE with any function to be mocked
void virPCIDeviceSetManaged(virPCIDevice *dev,
bool managed);
bool virPCIDeviceGetManaged(virPCIDevice *dev);
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
1:39 a.m.
New subject: [libvirt PATCH v2 15/15] qemu: automatically bind to a vfio variant driver, if available
Rather than always binding to the vfio-pci driver, use the new
function virPCIDeviceFindBestVFIOVariant() to see if the running
kernel has a VFIO variant driver available that is a better match for
the device, and if one is found, use that instead.
virPCIDeviceFindBestVFIOVariant() function reads the modalias file for
the given device from sysfs, then looks through
/lib/modules/${kernel_release}/modules.alias for the vfio_pci alias
that matches with the least number of wildcard ('*') fields.
The appropriate "VFIO variant" driver for a device will be the PCI
driver implemented by the discovered module - these drivers are
compatible with (and provide the entire API of) the standard vfio-pci
driver, but have additional device-specific APIs that can be useful
for, e.g., saving/restoring state for migration.
If a specific driver is named, that will still be used rather than
searching modules.alias; this makes it possible to force binding of
vfio-pci if there is an issue with the auto-selected variant driver.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/util/virpci.c | 242 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 242 insertions(+)
diff --git a/src/util/virpci.c b/src/util/virpci.c
index 885958eb99..40831a5294 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -30,6 +30,10 @@
#include <sys/stat.h>
#include <unistd.h>
+#ifndef WIN32
+# include <sys/utsname.h>
+#endif
+
#include "virlog.h"
#include "virerror.h"
#include "virfile.h"
@@ -1321,6 +1325,225 @@ virPCIDeviceFindDriver(virPCIDevice *dev)
}
+#ifdef __linux__
+typedef struct {
+ /* this is the decomposed version of a string like:
+ *
+ * vNNNNNNNNdNNNNNNNNsvNNNNNNNNsdNNNNNNNNbcNNscNNiNN
+ *
+ * (followed by a space or newline). The "NNNN" are always of the
+ * length in the example unless replaced with a wildcard ("*"),
+ * but we make no assumptions about length.
+ *
+ * Rather than name each field, we just put them
+ * all in an array of 6 elements, so that we
+ * can write a simple loop to compare them
+ */
+ char *fields[7]; /* v, d, sv, sd, bc, sc, i */
+} virPCIDeviceAliasInfo;
+
+
+/* NULL in last position makes parsing loop simpler */
+static const char *fieldnames[] = { "v", "d", "sv",
"sd", "bc", "sc", "i", NULL };
+
+
+static void
+virPCIDeviceAliasInfoFree(virPCIDeviceAliasInfo *info)
+{
+ if (info) {
+ size_t i;
+
+ for (i = 0; i < G_N_ELEMENTS(info->fields); i++)
+ g_free(info->fields[i]);
+
+ g_free(info);
+ }
+}
+
+G_DEFINE_AUTOPTR_CLEANUP_FUNC(virPCIDeviceAliasInfo, virPCIDeviceAliasInfoFree);
+
+
+static virPCIDeviceAliasInfo *
+virPCIDeviceAliasInfoNew(const char *str)
+{
+ const char *field = str;
+
+ size_t i;
+ g_autoptr(virPCIDeviceAliasInfo) ret = g_new0(virPCIDeviceAliasInfo, 1);
+
+ if (!str)
+ return g_steal_pointer(&ret);
+
+ /* initialize from str */
+ for (i = 0; i < G_N_ELEMENTS(ret->fields); i++) {
+ int len = strlen(fieldnames[i]);
+ const char *next;
+
+ if (strncmp(field, fieldnames[i], len))
+ return NULL;
+
+ field += len;
+ if (fieldnames[i + 1]) {
+ if (!(next = strstr(field, fieldnames[i + 1])))
+ return NULL;
+ } else {
+ next = field;
+ virSkipToSpace(&next);
+ }
+
+ ret->fields[i] = g_strndup(field, next - field);
+ field = next;
+ }
+
+ return g_steal_pointer(&ret);
+}
+
+
+static void
+virPCIDeviceAliasInfoPrint(virPCIDeviceAliasInfo *info)
+{
+ size_t i;
+
+ for (i = 0; i < G_N_ELEMENTS(info->fields); i++)
+ VIR_DEBUG("%s: '%s'", fieldnames[i], info->fields[i]);
+}
+
+
+static bool
+virPCIDeviceAliasInfoMatch(virPCIDeviceAliasInfo *orig,
+ virPCIDeviceAliasInfo *match,
+ int *wildCardCt)
+{
+ size_t i;
+
+ *wildCardCt = 0;
+
+ for (i = 0; i < G_N_ELEMENTS(orig->fields); i++) {
+ if (STREQ(match->fields[i], "*"))
+ (*wildCardCt)++;
+ else if (STRNEQ(orig->fields[i], match->fields[i]))
+ return false;
+ }
+ return true;
+}
+
+
+/* virPCIDeviceFindBestVFIOVariant:
+ *
+ * Find the "best" match of all vfio_pci aliases for @dev in the host
+ * modules.alias file. This uses the algorithm of finding every
+ * modules.alias line that begins with "vfio_pci:", then picking the
+ * one that matches the device's own modalias value (from the file of
+ * that name in the device's sysfs directory) with the fewest
+ * "wildcards" (* character, meaning "match any value for this
+ * attribute").
+ */
+static int
+virPCIDeviceFindBestVFIOVariant(virPCIDevice *dev,
+ char **moduleName)
+{
+ g_autofree char *devModAliasPath = NULL;
+ g_autofree char *devModAliasContent = NULL;
+ const char *devModAlias;
+ g_autoptr(virPCIDeviceAliasInfo) devModAliasInfo = NULL;
+ struct utsname unameInfo;
+ g_autofree char *modulesAliasPath = NULL;
+ g_autofree char *modulesAliasContent = NULL;
+ const char *line;
+ int currentBestWildcardCt = INT_MAX;
+
+ *moduleName = NULL;
+
+ /* get the modalias values for the device from sysfs */
+ devModAliasPath = virPCIFile(dev->name, "modalias");
+ if (virFileReadAll(devModAliasPath, 100, &devModAliasContent) < 0)
+ return 0;
+
+ VIR_DEBUG("modalias path: '%s' contents: '%s'",
+ devModAliasPath, devModAliasContent);
+
+ /* "pci:vNNNNNNNNdNNNNNNNNsvNNNNNNNNsdNNNNNNNNbcNNscNNiNN\n" */
+ if ((devModAlias = STRSKIP(devModAliasContent, "pci:")) == NULL ||
+ !(devModAliasInfo = virPCIDeviceAliasInfoNew(devModAlias))) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("device modalias file %1$s content has improper
format"),
+ devModAliasPath);
+ return -1;
+ }
+
+ virPCIDeviceAliasInfoPrint(devModAliasInfo);
+
+ uname(&unameInfo);
+ modulesAliasPath = g_strdup_printf("/lib/modules/%s/modules.alias",
+ unameInfo.release);
+ if (virFileReadAll(modulesAliasPath,
+ 4 * 1024 * 1024, &modulesAliasContent) < 0) {
+ return -1;
+ }
+
+ /* Look for all lines that are aliases for vfio_pci drivers.
+ * (The first line is always a comment, so we can be sure "alias"
+ * is preceded by a newline)
+ */
+ line = modulesAliasContent;
+
+ while ((line = strstr(line, "\nalias vfio_pci:"))) {
+ g_autoptr(virPCIDeviceAliasInfo) fileModAliasInfo = NULL;
+ int wildCardCt;
+
+ /* "alias vfio_pci:vNNNNNNNNdNNNNNNNNsvNNNNNNNNsdNNNNNNNNbcNNscNNiNN
XXXX\n" */
+ line += strlen("\nalias vfio_pci:");
+ if (!(fileModAliasInfo = virPCIDeviceAliasInfoNew(line)))
+ continue;
+
+ virPCIDeviceAliasInfoPrint(fileModAliasInfo);
+
+ if (virPCIDeviceAliasInfoMatch(devModAliasInfo,
+ fileModAliasInfo, &wildCardCt)) {
+
+ const char *aliasStart = strchr(line, ' ');
+ const char *aliasEnd = NULL;
+ g_autofree char *aliasName = NULL;
+
+ if (!aliasStart) {
+ VIR_WARN("malformed modules.alias vfio_pci: line");
+ continue;
+ }
+
+ aliasStart++;
+ line = aliasEnd = strchrnul(aliasStart, '\n');
+ aliasName = g_strndup(aliasStart, aliasEnd - aliasStart);
+
+ VIR_DEBUG("matching alias '%s' found, %d wildcards",
+ aliasName, wildCardCt);
+
+ if (wildCardCt < currentBestWildcardCt) {
+
+ /* this is a better match than previous */
+ currentBestWildcardCt = wildCardCt;
+ g_free(*moduleName);
+ *moduleName = g_steal_pointer(&aliasName);
+ }
+ }
+ }
+ return 0;
+}
+
+
+#else /* __linux__ */
+
+
+static int
+virPCIDeviceFindBestVFIOVariant(virPCIDevice *dev G_GNUC_UNUSED,
+ char **moduleName G_GNUC_UNUSED)
+{
+ virReportSystemError(ENOSYS, "%s",
+ _("VFIO device assignment is not available on this
platform"));
+ return -1;
+}
+#endif /* __linux__ */
+
+
int
virPCIDeviceUnbind(virPCIDevice *dev)
{
@@ -1431,6 +1654,22 @@ virPCIDeviceBindToStub(virPCIDevice *dev)
return -1;
}
+ if (dev->stubDriverType == VIR_PCI_STUB_DRIVER_VFIO
+ && !dev->stubDriverName) {
+ g_autofree char *autodetectModuleName = NULL;
+
+ /* automatically use a VFIO variant driver if available for
+ * this device.
+ */
+
+ if (virPCIDeviceFindBestVFIOVariant(dev, &autodetectModuleName) < 0)
+ return -1;
+
+ g_free(dev->stubDriverName);
+ dev->stubDriverName = g_steal_pointer(&autodetectModuleName);
+ }
+
+ /* if a driver name hasn't been decided by now, use default for this type */
if (!dev->stubDriverName) {
const char *stubDriverName = NULL;
@@ -1538,6 +1777,9 @@ virPCIDeviceReattach(virPCIDevice *dev,
return 0;
}
+
+
+
static char *
virPCIDeviceReadID(virPCIDevice *dev, const char *id_name)
{
--
2.41.0
9:39 a.m.
New subject: [libvirt PATCH v2 15/15] qemu: automatically bind to a vfio
variant driver, if available
On Mon, Nov 06, 2023 at 02:39:00 -0500, Laine Stump wrote:
Rather than always binding to the vfio-pci driver, use the new
function virPCIDeviceFindBestVFIOVariant() to see if the running
kernel has a VFIO variant driver available that is a better match for
the device, and if one is found, use that instead.
virPCIDeviceFindBestVFIOVariant() function reads the modalias file for
the given device from sysfs, then looks through
/lib/modules/${kernel_release}/modules.alias for the vfio_pci alias
that matches with the least number of wildcard ('*') fields.
The appropriate "VFIO variant" driver for a device will be the PCI
driver implemented by the discovered module - these drivers are
compatible with (and provide the entire API of) the standard vfio-pci
driver, but have additional device-specific APIs that can be useful
for, e.g., saving/restoring state for migration.
If a specific driver is named, that will still be used rather than
searching modules.alias; this makes it possible to force binding of
vfio-pci if there is an issue with the auto-selected variant driver.
Signed-off-by: Laine Stump <laine(a)redhat.com>
---
src/util/virpci.c | 242 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 242 insertions(+)
diff --git a/src/util/virpci.c b/src/util/virpci.c
index 885958eb99..40831a5294 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -30,6 +30,10 @@
#include <sys/stat.h>
#include <unistd.h>
+#ifndef WIN32
+# include <sys/utsname.h>
+#endif
+
#include "virlog.h"
#include "virerror.h"
#include "virfile.h"
@@ -1321,6 +1325,225 @@ virPCIDeviceFindDriver(virPCIDevice *dev)
}
+#ifdef __linux__
+typedef struct {
+ /* this is the decomposed version of a string like:
+ *
+ * vNNNNNNNNdNNNNNNNNsvNNNNNNNNsdNNNNNNNNbcNNscNNiNN
+ *
+ * (followed by a space or newline). The "NNNN" are always of the
+ * length in the example unless replaced with a wildcard ("*"),
+ * but we make no assumptions about length.
+ *
+ * Rather than name each field, we just put them
+ * all in an array of 6 elements, so that we
^^^
+ * can write a simple loop to compare them
+ */
+ char *fields[7]; /* v, d, sv, sd, bc, sc, i */
^^^ ...
+} virPCIDeviceAliasInfo;
+
+
+/* NULL in last position makes parsing loop simpler */
+static const char *fieldnames[] = { "v", "d", "sv",
"sd", "bc", "sc", "i", NULL };
+
+
+static void
+virPCIDeviceAliasInfoFree(virPCIDeviceAliasInfo *info)
+{
+ if (info) {
+ size_t i;
+
+ for (i = 0; i < G_N_ELEMENTS(info->fields); i++)
+ g_free(info->fields[i]);
+
+ g_free(info);
+ }
+}
+
+G_DEFINE_AUTOPTR_CLEANUP_FUNC(virPCIDeviceAliasInfo, virPCIDeviceAliasInfoFree);
+
+
+static virPCIDeviceAliasInfo *
+virPCIDeviceAliasInfoNew(const char *str)
+{
+ const char *field = str;
+
+ size_t i;
+ g_autoptr(virPCIDeviceAliasInfo) ret = g_new0(virPCIDeviceAliasInfo, 1);
+
+ if (!str)
+ return g_steal_pointer(&ret);
So here you return an empty array as "success" if the input string is
empty, but note that neither virPCIDeviceAliasInfoMatch nor
virPCIDeviceAliasInfoPrint properly handle the fields being NULL.
None of the callers use this scenario so it should be removed.
+
+ /* initialize from str */
+ for (i = 0; i < G_N_ELEMENTS(ret->fields); i++) {
+ int len = strlen(fieldnames[i]);
+ const char *next;
+
+ if (strncmp(field, fieldnames[i], len))
+ return NULL;
+
+ field += len;
+ if (fieldnames[i + 1]) {
+ if (!(next = strstr(field, fieldnames[i + 1])))
+ return NULL;
+ } else {
+ next = field;
+ virSkipToSpace(&next);
+ }
+
+ ret->fields[i] = g_strndup(field, next - field);
+ field = next;
+ }
+
+ return g_steal_pointer(&ret);
+}
+
+
+static void
+virPCIDeviceAliasInfoPrint(virPCIDeviceAliasInfo *info)
+{
+ size_t i;
+
+ for (i = 0; i < G_N_ELEMENTS(info->fields); i++)
+ VIR_DEBUG("%s: '%s'", fieldnames[i], info->fields[i]);
+}
+
+
+static bool
+virPCIDeviceAliasInfoMatch(virPCIDeviceAliasInfo *orig,
+ virPCIDeviceAliasInfo *match,
+ int *wildCardCt)
unsigned, negative values don't seem to make sense.
+{
+ size_t i;
+
+ *wildCardCt = 0;
+
+ for (i = 0; i < G_N_ELEMENTS(orig->fields); i++) {
+ if (STREQ(match->fields[i], "*"))
+ (*wildCardCt)++;
+ else if (STRNEQ(orig->fields[i], match->fields[i]))
+ return false;
+ }
+ return true;
+}
+
+
+/* virPCIDeviceFindBestVFIOVariant:
+ *
+ * Find the "best" match of all vfio_pci aliases for @dev in the host
+ * modules.alias file. This uses the algorithm of finding every
+ * modules.alias line that begins with "vfio_pci:", then picking the
+ * one that matches the device's own modalias value (from the file of
+ * that name in the device's sysfs directory) with the fewest
+ * "wildcards" (* character, meaning "match any value for this
+ * attribute").
+ */
+static int
+virPCIDeviceFindBestVFIOVariant(virPCIDevice *dev,
+ char **moduleName)
+{
+ g_autofree char *devModAliasPath = NULL;
+ g_autofree char *devModAliasContent = NULL;
+ const char *devModAlias;
+ g_autoptr(virPCIDeviceAliasInfo) devModAliasInfo = NULL;
+ struct utsname unameInfo;
+ g_autofree char *modulesAliasPath = NULL;
+ g_autofree char *modulesAliasContent = NULL;
+ const char *line;
+ int currentBestWildcardCt = INT_MAX;
Unsigned.
+
+ *moduleName = NULL;
+
+ /* get the modalias values for the device from sysfs */
+ devModAliasPath = virPCIFile(dev->name, "modalias");
If you expect this file to be missing ...
+ if (virFileReadAll(devModAliasPath, 100,
&devModAliasContent) < 0)
... then you need to check whether it exists, as this will spam logs.
And also we most likely should reset the local instance of error in this
code path as virFileReadAll sets it.
+ return 0;
+
+ VIR_DEBUG("modalias path: '%s' contents: '%s'",
+ devModAliasPath, devModAliasContent);
+
+ /* "pci:vNNNNNNNNdNNNNNNNNsvNNNNNNNNsdNNNNNNNNbcNNscNNiNN\n" */
+ if ((devModAlias = STRSKIP(devModAliasContent, "pci:")) == NULL ||
+ !(devModAliasInfo = virPCIDeviceAliasInfoNew(devModAlias))) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("device modalias file %1$s content has improper
format"),
+ devModAliasPath);
+ return -1;
+ }
+
+ virPCIDeviceAliasInfoPrint(devModAliasInfo);
Since this logs 7 lines into the debug log I don't think it's a great
idea to have it in production. If you need to be sure that the parser
processes teh modalias correctly, then please add unit tests instead.
Logging the raw string, which happens above should be sufficient for
debugging.
+
+ uname(&unameInfo);
+ modulesAliasPath = g_strdup_printf("/lib/modules/%s/modules.alias",
+ unameInfo.release);
+ if (virFileReadAll(modulesAliasPath,
+ 4 * 1024 * 1024, &modulesAliasContent) < 0) {
Note that the file currently has 1.3MiB already, I'm not sure what the
potenital for growth is though, but this leaves less than an order of
magnitude in reserve.
Additionally the code below only currently looks at 2 of the 25k lines
in the file. Maybe it's worth caching the relevant lines?
+ return -1;
+ }
+
+ /* Look for all lines that are aliases for vfio_pci drivers.
+ * (The first line is always a comment, so we can be sure "alias"
+ * is preceded by a newline)
+ */
+ line = modulesAliasContent;
+
+ while ((line = strstr(line, "\nalias vfio_pci:"))) {
+ g_autoptr(virPCIDeviceAliasInfo) fileModAliasInfo = NULL;
+ int wildCardCt;
+
+ /* "alias vfio_pci:vNNNNNNNNdNNNNNNNNsvNNNNNNNNsdNNNNNNNNbcNNscNNiNN
XXXX\n" */
+ line += strlen("\nalias vfio_pci:");
+ if (!(fileModAliasInfo = virPCIDeviceAliasInfoNew(line)))
+ continue;
+
+ virPCIDeviceAliasInfoPrint(fileModAliasInfo);
Logging the matched line should be sufficient. Please remove the overly
verbose virPCIDeviceAliasInfoPrint.
+
+ if (virPCIDeviceAliasInfoMatch(devModAliasInfo,
+ fileModAliasInfo, &wildCardCt)) {
+
+ const char *aliasStart = strchr(line, ' ');
+ const char *aliasEnd = NULL;
+ g_autofree char *aliasName = NULL;
+
+ if (!aliasStart) {
+ VIR_WARN("malformed modules.alias vfio_pci: line");
+ continue;
+ }
+
+ aliasStart++;
+ line = aliasEnd = strchrnul(aliasStart, '\n');
+ aliasName = g_strndup(aliasStart, aliasEnd - aliasStart);
+
+ VIR_DEBUG("matching alias '%s' found, %d wildcards",
+ aliasName, wildCardCt);
Possibly worth logging currentBestWildcardCt too?
+
+ if (wildCardCt < currentBestWildcardCt) {
+
+ /* this is a better match than previous */
+ currentBestWildcardCt = wildCardCt;
+ g_free(*moduleName);
+ *moduleName = g_steal_pointer(&aliasName);
+ }
+ }
+ }
+ return 0;
+}
+
+
+#else /* __linux__ */
+
+
+static int
+virPCIDeviceFindBestVFIOVariant(virPCIDevice *dev G_GNUC_UNUSED,
+ char **moduleName G_GNUC_UNUSED)
+{
+ virReportSystemError(ENOSYS, "%s",
+ _("VFIO device assignment is not available on this
platform"));
+ return -1;
+}
+#endif /* __linux__ */
+
+
int
virPCIDeviceUnbind(virPCIDevice *dev)
{
@@ -1431,6 +1654,22 @@ virPCIDeviceBindToStub(virPCIDevice *dev)
return -1;
}
+ if (dev->stubDriverType == VIR_PCI_STUB_DRIVER_VFIO
+ && !dev->stubDriverName) {
Logic operators are commonly placed at the end of the line before.
+ g_autofree char *autodetectModuleName = NULL;
+
+ /* automatically use a VFIO variant driver if available for
+ * this device.
+ */
+
+ if (virPCIDeviceFindBestVFIOVariant(dev, &autodetectModuleName) < 0)
+ return -1;
+
+ g_free(dev->stubDriverName);
+ dev->stubDriverName = g_steal_pointer(&autodetectModuleName);
+ }
+
+ /* if a driver name hasn't been decided by now, use default for this type */
if (!dev->stubDriverName) {
const char *stubDriverName = NULL;
@@ -1538,6 +1777,9 @@ virPCIDeviceReattach(virPCIDevice *dev,
return 0;
}
+
+
+
Spurious whitespace change.
static char *
virPCIDeviceReadID(virPCIDevice *dev, const char *id_name)
{
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
7:01 p.m.
New subject: [libvirt PATCH v2 15/15] qemu: automatically bind to a vfio
variant driver, if available
On 11/28/23 10:39 AM, Peter Krempa wrote:
On Mon, Nov 06, 2023 at 02:39:00 -0500, Laine Stump wrote:
> Rather than always binding to the vfio-pci driver, use the new
> function virPCIDeviceFindBestVFIOVariant() to see if the running
> kernel has a VFIO variant driver available that is a better match for
> the device, and if one is found, use that instead.
>
> virPCIDeviceFindBestVFIOVariant() function reads the modalias file for
> the given device from sysfs, then looks through
> /lib/modules/${kernel_release}/modules.alias for the vfio_pci alias
> that matches with the least number of wildcard ('*') fields.
>
> The appropriate "VFIO variant" driver for a device will be the PCI
> driver implemented by the discovered module - these drivers are
> compatible with (and provide the entire API of) the standard vfio-pci
> driver, but have additional device-specific APIs that can be useful
> for, e.g., saving/restoring state for migration.
>
> If a specific driver is named, that will still be used rather than
> searching modules.alias; this makes it possible to force binding of
> vfio-pci if there is an issue with the auto-selected variant driver.
>
> Signed-off-by: Laine Stump <laine(a)redhat.com>
> ---
> src/util/virpci.c | 242 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 242 insertions(+)
>
> diff --git a/src/util/virpci.c b/src/util/virpci.c
> index 885958eb99..40831a5294 100644
> --- a/src/util/virpci.c
> +++ b/src/util/virpci.c
> @@ -30,6 +30,10 @@
> #include <sys/stat.h>
> #include <unistd.h>
>
> +#ifndef WIN32
> +# include <sys/utsname.h>
> +#endif
> +
> #include "virlog.h"
> #include "virerror.h"
> #include "virfile.h"
> @@ -1321,6 +1325,225 @@ virPCIDeviceFindDriver(virPCIDevice *dev)
> }
>
>
> +#ifdef __linux__
> +typedef struct {
> + /* this is the decomposed version of a string like:
> + *
> + * vNNNNNNNNdNNNNNNNNsvNNNNNNNNsdNNNNNNNNbcNNscNNiNN
> + *
> + * (followed by a space or newline). The "NNNN" are always of the
> + * length in the example unless replaced with a wildcard ("*"),
> + * but we make no assumptions about length.
> + *
> + * Rather than name each field, we just put them
> + * all in an array of 6 elements, so that we
^^^
> + * can write a simple loop to compare them
> + */
> + char *fields[7]; /* v, d, sv, sd, bc, sc, i */
^^^ ...
> +} virPCIDeviceAliasInfo;
> +
> +
> +/* NULL in last position makes parsing loop simpler */
> +static const char *fieldnames[] = { "v", "d", "sv",
"sd", "bc", "sc", "i", NULL };
> +
> +
> +static void
> +virPCIDeviceAliasInfoFree(virPCIDeviceAliasInfo *info)
> +{
> + if (info) {
> + size_t i;
> +
> + for (i = 0; i < G_N_ELEMENTS(info->fields); i++)
> + g_free(info->fields[i]);
> +
> + g_free(info);
> + }
> +}
> +
> +G_DEFINE_AUTOPTR_CLEANUP_FUNC(virPCIDeviceAliasInfo, virPCIDeviceAliasInfoFree);
> +
> +
> +static virPCIDeviceAliasInfo *
> +virPCIDeviceAliasInfoNew(const char *str)
> +{
> + const char *field = str;
> +
> + size_t i;
> + g_autoptr(virPCIDeviceAliasInfo) ret = g_new0(virPCIDeviceAliasInfo, 1);
> +
> + if (!str)
> + return g_steal_pointer(&ret);
So here you return an empty array as "success" if the input string is
empty, but note that neither virPCIDeviceAliasInfoMatch nor
virPCIDeviceAliasInfoPrint properly handle the fields being NULL.
None of the callers use this scenario so it should be removed.
Done.
> +
> + /* initialize from str */
> + for (i = 0; i < G_N_ELEMENTS(ret->fields); i++) {
> + int len = strlen(fieldnames[i]);
> + const char *next;
> +
> + if (strncmp(field, fieldnames[i], len))
> + return NULL;
> +
> + field += len;
> + if (fieldnames[i + 1]) {
> + if (!(next = strstr(field, fieldnames[i + 1])))
> + return NULL;
> + } else {
> + next = field;
> + virSkipToSpace(&next);
> + }
> +
> + ret->fields[i] = g_strndup(field, next - field);
> + field = next;
> + }
> +
> + return g_steal_pointer(&ret);
> +}
> +
> +
> +static void
> +virPCIDeviceAliasInfoPrint(virPCIDeviceAliasInfo *info)
> +{
> + size_t i;
> +
> + for (i = 0; i < G_N_ELEMENTS(info->fields); i++)
> + VIR_DEBUG("%s: '%s'", fieldnames[i], info->fields[i]);
> +}
> +
> +
> +static bool
> +virPCIDeviceAliasInfoMatch(virPCIDeviceAliasInfo *orig,
> + virPCIDeviceAliasInfo *match,
> + int *wildCardCt)
unsigned, negative values don't seem to make sense.
Okay, I've made them all unsigned.
> +{
> + size_t i;
> +
> + *wildCardCt = 0;
> +
> + for (i = 0; i < G_N_ELEMENTS(orig->fields); i++) {
> + if (STREQ(match->fields[i], "*"))
> + (*wildCardCt)++;
> + else if (STRNEQ(orig->fields[i], match->fields[i]))
> + return false;
> + }
> + return true;
> +}
> +
> +
> +/* virPCIDeviceFindBestVFIOVariant:
> + *
> + * Find the "best" match of all vfio_pci aliases for @dev in the host
> + * modules.alias file. This uses the algorithm of finding every
> + * modules.alias line that begins with "vfio_pci:", then picking the
> + * one that matches the device's own modalias value (from the file of
> + * that name in the device's sysfs directory) with the fewest
> + * "wildcards" (* character, meaning "match any value for this
> + * attribute").
> + */
> +static int
> +virPCIDeviceFindBestVFIOVariant(virPCIDevice *dev,
> + char **moduleName)
> +{
> + g_autofree char *devModAliasPath = NULL;
> + g_autofree char *devModAliasContent = NULL;
> + const char *devModAlias;
> + g_autoptr(virPCIDeviceAliasInfo) devModAliasInfo = NULL;
> + struct utsname unameInfo;
> + g_autofree char *modulesAliasPath = NULL;
> + g_autofree char *modulesAliasContent = NULL;
> + const char *line;
> + int currentBestWildcardCt = INT_MAX;
Unsigned.
> +
> + *moduleName = NULL;
> +
> + /* get the modalias values for the device from sysfs */
> + devModAliasPath = virPCIFile(dev->name, "modalias");
If you expect this file to be missing ...
> + if (virFileReadAll(devModAliasPath, 100, &devModAliasContent) < 0)
... then you need to check whether it exists, as this will spam logs.
It should never be missing. *Every* pci device should have a modalias
file, so if it's missing that's something that everyone should know
about. Just in case that *did* happen, I was reluctant to have the
entire operation fail (just because it would mean that something that
previously worked would no longer work), but after talking to Alex
(Williamson) I've decided that if the modalias file is missing, that is
enough indication that something is broken that we *should* log an error
and fail.
I changed it to return -1
And also we most likely should reset the local instance of error in
this
code path as virFileReadAll sets it.
> + return 0;
> +
> + VIR_DEBUG("modalias path: '%s' contents: '%s'",
> + devModAliasPath, devModAliasContent);
> +
> + /* "pci:vNNNNNNNNdNNNNNNNNsvNNNNNNNNsdNNNNNNNNbcNNscNNiNN\n" */
> + if ((devModAlias = STRSKIP(devModAliasContent, "pci:")) == NULL ||
> + !(devModAliasInfo = virPCIDeviceAliasInfoNew(devModAlias))) {
> + virReportError(VIR_ERR_INTERNAL_ERROR,
> + _("device modalias file %1$s content has improper
format"),
> + devModAliasPath);
> + return -1;
> + }
> +
> + virPCIDeviceAliasInfoPrint(devModAliasInfo);
Since this logs 7 lines into the debug log I don't think it's a great
idea to have it in production. If you need to be sure that the parser
processes teh modalias correctly, then please add unit tests instead.
Logging the raw string, which happens above should be sufficient for
debugging.
Agreed. I had that in there when I was writing the code, and should have
removed it before I posted - it really is too verbose and the "parsing"
is so simplistic that it doesn't need a test case. I removed all trace
of virPCIDeiceAliasInfoPrint().
> +
> + uname(&unameInfo);
> + modulesAliasPath = g_strdup_printf("/lib/modules/%s/modules.alias",
> + unameInfo.release);
> + if (virFileReadAll(modulesAliasPath,
> + 4 * 1024 * 1024, &modulesAliasContent) < 0) {
Note that the file currently has 1.3MiB already, I'm not sure what the
potenital for growth is though, but this leaves less than an order of
magnitude in reserve.
How about increasing it to 8MB? Still too small?
Additionally the code below only currently looks at 2 of the 25k lines
in the file. Maybe it's worth caching the relevant lines?
Yes, I agree with this. I suppose the "proper" way to do that is to use
virfilecache (code re-use and all that), but it will take me some time
to understand that, as I've never looked at it until just now :-P.
How about a promise to do a followup "soon" that caches the useful lines
and re-uses them?
> + return -1;
> + }
> +
> + /* Look for all lines that are aliases for vfio_pci drivers.
> + * (The first line is always a comment, so we can be sure "alias"
> + * is preceded by a newline)
> + */
> + line = modulesAliasContent;
> +
> + while ((line = strstr(line, "\nalias vfio_pci:"))) {
> + g_autoptr(virPCIDeviceAliasInfo) fileModAliasInfo = NULL;
> + int wildCardCt;
> +
> + /* "alias vfio_pci:vNNNNNNNNdNNNNNNNNsvNNNNNNNNsdNNNNNNNNbcNNscNNiNN
XXXX\n" */
> + line += strlen("\nalias vfio_pci:");
> + if (!(fileModAliasInfo = virPCIDeviceAliasInfoNew(line)))
> + continue;
> +
> + virPCIDeviceAliasInfoPrint(fileModAliasInfo);
Logging the matched line should be sufficient. Please remove the overly
verbose virPCIDeviceAliasInfoPrint.
It's gone. It's over. </frodo>
> +
> + if (virPCIDeviceAliasInfoMatch(devModAliasInfo,
> + fileModAliasInfo, &wildCardCt)) {
> +
> + const char *aliasStart = strchr(line, ' ');
> + const char *aliasEnd = NULL;
> + g_autofree char *aliasName = NULL;
> +
> + if (!aliasStart) {
> + VIR_WARN("malformed modules.alias vfio_pci: line");
> + continue;
> + }
> +
> + aliasStart++;
> + line = aliasEnd = strchrnul(aliasStart, '\n');
> + aliasName = g_strndup(aliasStart, aliasEnd - aliasStart);
> +
> + VIR_DEBUG("matching alias '%s' found, %d wildcards",
> + aliasName, wildCardCt);
Possibly worth logging currentBestWildcardCt too?
Sure, why not - doesn't add any extra lines.
> +
> + if (wildCardCt < currentBestWildcardCt) {
> +
> + /* this is a better match than previous */
> + currentBestWildcardCt = wildCardCt;
> + g_free(*moduleName);
> + *moduleName = g_steal_pointer(&aliasName);
> + }
> + }
> + }
> + return 0;
> +}
> +
> +
> +#else /* __linux__ */
> +
> +
> +static int
> +virPCIDeviceFindBestVFIOVariant(virPCIDevice *dev G_GNUC_UNUSED,
> + char **moduleName G_GNUC_UNUSED)
> +{
> + virReportSystemError(ENOSYS, "%s",
> + _("VFIO device assignment is not available on this
platform"));
> + return -1;
> +}
> +#endif /* __linux__ */
> +
> +
> int
> virPCIDeviceUnbind(virPCIDevice *dev)
> {
> @@ -1431,6 +1654,22 @@ virPCIDeviceBindToStub(virPCIDevice *dev)
> return -1;
> }
>
> + if (dev->stubDriverType == VIR_PCI_STUB_DRIVER_VFIO
> + && !dev->stubDriverName) {
Logic operators are commonly placed at the end of the line before.
It's been 15 years, and I *still* remember this backwards half the time!!
> + g_autofree char *autodetectModuleName = NULL;
> +
> + /* automatically use a VFIO variant driver if available for
> + * this device.
> + */
> +
> + if (virPCIDeviceFindBestVFIOVariant(dev, &autodetectModuleName) < 0)
> + return -1;
> +
> + g_free(dev->stubDriverName);
> + dev->stubDriverName = g_steal_pointer(&autodetectModuleName);
> + }
> +
> + /* if a driver name hasn't been decided by now, use default for this type
*/
> if (!dev->stubDriverName) {
>
> const char *stubDriverName = NULL;
> @@ -1538,6 +1777,9 @@ virPCIDeviceReattach(virPCIDevice *dev,
> return 0;
> }
>
> +
> +
> +
Spurious whitespace change.
> static char *
> virPCIDeviceReadID(virPCIDevice *dev, const char *id_name)
> {
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
_______________________________________________
Devel mailing list -- devel(a)lists.libvirt.org
To unsubscribe send an email to devel-leave(a)lists.libvirt.org
2:20 a.m.
New subject: [libvirt PATCH v2 15/15] qemu: automatically bind to a vfio
variant driver, if available
On Thu, Jan 04, 2024 at 20:01:44 -0500, Laine Stump wrote:
On 11/28/23 10:39 AM, Peter Krempa wrote:
> On Mon, Nov 06, 2023 at 02:39:00 -0500, Laine Stump wrote:
> > Rather than always binding to the vfio-pci driver, use the new
> > function virPCIDeviceFindBestVFIOVariant() to see if the running
> > kernel has a VFIO variant driver available that is a better match for
> > the device, and if one is found, use that instead.
> >
> > virPCIDeviceFindBestVFIOVariant() function reads the modalias file for
> > the given device from sysfs, then looks through
> > /lib/modules/${kernel_release}/modules.alias for the vfio_pci alias
> > that matches with the least number of wildcard ('*') fields.
> >
> > The appropriate "VFIO variant" driver for a device will be the PCI
> > driver implemented by the discovered module - these drivers are
> > compatible with (and provide the entire API of) the standard vfio-pci
> > driver, but have additional device-specific APIs that can be useful
> > for, e.g., saving/restoring state for migration.
> >
> > If a specific driver is named, that will still be used rather than
> > searching modules.alias; this makes it possible to force binding of
> > vfio-pci if there is an issue with the auto-selected variant driver.
> >
> > Signed-off-by: Laine Stump <laine(a)redhat.com>
> > ---
> > src/util/virpci.c | 242 ++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 242 insertions(+)
[...]
> > +
> > + uname(&unameInfo);
> > + modulesAliasPath =
g_strdup_printf("/lib/modules/%s/modules.alias",
> > + unameInfo.release);
> > + if (virFileReadAll(modulesAliasPath,
> > + 4 * 1024 * 1024, &modulesAliasContent) < 0) {
>
> Note that the file currently has 1.3MiB already, I'm not sure what the
> potenital for growth is though, but this leaves less than an order of
> magnitude in reserve.
How about increasing it to 8MB? Still too small?
Ideally we'd stream-process the file, since the code looks at single
lines at time, I'm not sure whether we have some prior art in this
regard.
> Additionally the code below only currently looks at 2 of the 25k
lines
> in the file. Maybe it's worth caching the relevant lines?
Yes, I agree with this. I suppose the "proper" way to do that is to use
virfilecache (code re-use and all that), but it will take me some time to
understand that, as I've never looked at it until just now :-P.
How about a promise to do a followup "soon" that caches the useful lines and
re-uses them?
Honestly I don't think there's too much value in caching it on disk. A
runtime cache would be fine.
It's fine from my side if it's done later. If you keep reading of the
contents into a buffer and processing that add a comment stating that it
might not be enough. The code will break once the file size exceeds the
buffer size.
12:47 p.m.
ping
On 11/6/23 2:38 AM, Laine Stump wrote:
(Thisis "V2 of Part 2". "V1 of Part 2" is here:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5G...
)
Part 1 (which simply made it possible to use virsh nodedev-detach to
bind a device to a manually-specified variant driver, and at guest
runtime allowed libvirt to ignore the fact that the driver found to
the device was something other than exactly "vfio-pci") was here:
https://listman.redhat.com/archives/libvir-list/2023-August/241338.html
and pushed upstream as of commit v9.6.0-153-g24beaffec3
Part 2 adds two new pieces of functionality:
1) It is possible to manually specify a VFIO variant driver (or force
the generic vfio-pci driver) for a device in the domain XML with,
e.g.:
<driver name='mlx5_vfio_pci'/>
(for the former) or:
<driver name='vfio-pci'/>
(for the latter).
2) By default libvirt will now find the "best match" VFIO or VFIO
variant driver by comparing the device's modalias file contents (in
sysfs) with vfio drivers found in the running kernel's
modules.alias file. This means that "virsh nodedev-detach" of a
host device will bind it to its appropriate VFIO variant driver (if
one is available), and also if a <hostdev> decice in a domain
config has "managed='yes'", libvirt will bind it to a variant
driver if possible (in order to force binding to the basic vfio-pci
driver instead, you just need to add the <driver> element mentioned
above).
The first 12 patches are all just getting (1) going (a lot of it is
refactoring code to use common code for the four places that use the
hostdev <driver> element), and the final 3 patches implement (2).
More details are spread along the way.
Differences from V1:
I squashed together a couple of the patches, and fixed some things that caused
CI jobs to fail (I'd forgotten to push the branch to gitlab and
trigger CI).
Laine Stump (15):
util: properly deal with module vs. driver when binding device to
driver
schema: consolidate RNG for all hostdev <driver> elements
conf: move/rename hostdev PCI driver type enum to device_conf.h
conf: normalize hostdev <driver> parsing to simplify adding new attr
conf: put hostdev PCI backend into a struct
conf: use virDeviceHostdevPCIDriverInfo in network and networkport
objects
conf: split out hostdev <driver> parse/format to their own functions
conf: use new common parser/formatter for hostdev driver in network
XML
tests: remove explicit <driver name='vfio'/> from hostdev test cases
xen: explicitly set hostdev driver.type at runtime, not in postparse
conf: replace virHostdevIsVFIODevice with virHostdevIsPCIDevice
conf: support manually specifying VFIO variant driver in <hostdev> XML
util: new function virStringSkipToSpace()
tests: mock virPCIDevice(BindTo|UnbindFrom)Stub with nop functions
qemu: automatically bind to a vfio variant driver, if available
docs/formatdomain.rst | 55 ++-
src/conf/device_conf.c | 75 +++
src/conf/device_conf.h | 27 ++
src/conf/domain_capabilities.c | 2 +-
src/conf/domain_capabilities.h | 2 +-
src/conf/domain_conf.c | 98 +---
src/conf/domain_conf.h | 18 +-
src/conf/network_conf.c | 43 +-
src/conf/network_conf.h | 17 +-
src/conf/schemas/basictypes.rng | 20 +
src/conf/schemas/domaincommon.rng | 173 ++++---
src/conf/schemas/network.rng | 10 +-
src/conf/schemas/networkport.rng | 10 +-
src/conf/virconftypes.h | 2 +
src/conf/virnetworkportdef.c | 22 +-
src/conf/virnetworkportdef.h | 4 +-
src/hypervisor/virhostdev.c | 16 +-
src/hypervisor/virhostdev.h | 2 -
src/libvirt_private.syms | 10 +-
src/libxl/libxl_capabilities.c | 2 +-
src/libxl/libxl_domain.c | 65 ++-
src/libxl/libxl_driver.c | 25 +-
src/network/bridge_driver.c | 2 +-
src/qemu/qemu_capabilities.c | 4 +-
src/qemu/qemu_command.c | 14 +-
src/qemu/qemu_domain.c | 29 +-
src/qemu/qemu_hostdev.c | 2 +-
src/qemu/qemu_hotplug.c | 2 +-
src/qemu/qemu_validate.c | 6 +-
src/security/security_apparmor.c | 2 +-
src/security/security_dac.c | 4 +-
src/security/security_selinux.c | 4 +-
src/security/virt-aa-helper.c | 8 +-
src/util/virpci.c | 438 ++++++++++++++++--
src/util/virpci.h | 3 +
src/util/virstring.c | 17 +
src/util/virstring.h | 1 +
tests/domaincapstest.c | 4 +-
tests/libxlxml2domconfigdata/moredevs-hvm.xml | 1 -
tests/networkxml2xmlin/hostdev-pf-old.xml | 8 +
tests/networkxml2xmlin/hostdev-pf.xml | 2 +-
tests/networkxml2xmlout/hostdev-pf-old.xml | 8 +
tests/networkxml2xmlout/hostdev-pf.xml | 2 +-
tests/networkxml2xmltest.c | 6 +
tests/qemuhotplugmock.c | 15 +
.../qemuhotplug-hostdev-pci.xml | 1 -
.../qemuhotplug-base-live+hostdev-pci.xml | 2 +-
...uhotplug-pseries-base-live+hostdev-pci.xml | 2 +-
tests/qemustatusxml2xmldata/modern-in.xml | 2 +-
.../hostdev-pci-address-unassigned.xml | 4 -
.../hostdev-pci-multifunction.xml | 7 -
.../hostdev-vfio-multidomain.xml | 1 -
.../hostdev-vfio-zpci-autogenerate-fids.xml | 2 -
.../hostdev-vfio-zpci-autogenerate-uids.xml | 2 -
.../hostdev-vfio-zpci-autogenerate.xml | 1 -
.../hostdev-vfio-zpci-boundaries.xml | 2 -
.../hostdev-vfio-zpci-ccw-memballoon.xml | 1 -
.../hostdev-vfio-zpci-duplicate.xml | 2 -
...ostdev-vfio-zpci-invalid-uid-valid-fid.xml | 1 -
.../hostdev-vfio-zpci-multidomain-many.xml | 8 -
.../hostdev-vfio-zpci-set-zero.xml | 1 -
.../hostdev-vfio-zpci-uid-set-zero.xml | 1 -
.../hostdev-vfio-zpci-wrong-arch.xml | 1 -
tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 1 -
.../hostdev-vfio.x86_64-latest.args | 5 +-
tests/qemuxml2argvdata/hostdev-vfio.xml | 19 +-
.../net-hostdev-vfio-multidomain.xml | 1 -
tests/qemuxml2argvdata/net-hostdev-vfio.xml | 1 -
tests/qemuxml2argvdata/pseries-hostdevs-1.xml | 3 -
tests/qemuxml2argvdata/pseries-hostdevs-2.xml | 2 -
tests/qemuxml2argvdata/pseries-hostdevs-3.xml | 2 -
...v-pci-address-unassigned.x86_64-latest.xml | 4 -
...ostdev-pci-multifunction.x86_64-latest.xml | 7 -
...io-zpci-autogenerate-fids.s390x-latest.xml | 2 -
...io-zpci-autogenerate-uids.s390x-latest.xml | 2 -
...ev-vfio-zpci-autogenerate.s390x-latest.xml | 1 -
...tdev-vfio-zpci-boundaries.s390x-latest.xml | 2 -
...-vfio-zpci-ccw-memballoon.s390x-latest.xml | 1 -
...fio-zpci-multidomain-many.s390x-latest.xml | 8 -
.../hostdev-vfio-zpci.s390x-latest.xml | 1 -
.../hostdev-vfio.x86_64-latest.xml | 24 +-
.../net-hostdev-vfio.x86_64-latest.xml | 1 -
.../pseries-hostdevs-1.ppc64-latest.xml | 3 -
.../pseries-hostdevs-2.ppc64-latest.xml | 2 -
.../pseries-hostdevs-3.ppc64-latest.xml | 2 -
tests/virhostdevtest.c | 2 +-
.../plug-hostdev-pci-unmanaged.xml | 2 +-
.../plug-hostdev-pci.xml | 2 +-
tests/xlconfigdata/test-fullvirt-pci.xml | 2 -
tests/xmconfigdata/test-pci-dev-syntax.xml | 2 -
tests/xmconfigdata/test-pci-devs.xml | 2 -
tools/virsh-completer-nodedev.c | 4 +-
92 files changed, 933 insertions(+), 498 deletions(-)
create mode 100644 tests/networkxml2xmlin/hostdev-pf-old.xml
create mode 100644 tests/networkxml2xmlout/hostdev-pf-old.xml
12:43 p.m.
Re-ping :-)
On 11/6/23 2:38 AM, Laine Stump wrote:
(Thisis "V2 of Part 2". "V1 of Part 2" is here:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5G...
)
Part 1 (which simply made it possible to use virsh nodedev-detach to
bind a device to a manually-specified variant driver, and at guest
runtime allowed libvirt to ignore the fact that the driver found to
the device was something other than exactly "vfio-pci") was here:
https://listman.redhat.com/archives/libvir-list/2023-August/241338.html
and pushed upstream as of commit v9.6.0-153-g24beaffec3
Part 2 adds two new pieces of functionality:
1) It is possible to manually specify a VFIO variant driver (or force
the generic vfio-pci driver) for a device in the domain XML with,
e.g.:
<driver name='mlx5_vfio_pci'/>
(for the former) or:
<driver name='vfio-pci'/>
(for the latter).
2) By default libvirt will now find the "best match" VFIO or VFIO
variant driver by comparing the device's modalias file contents (in
sysfs) with vfio drivers found in the running kernel's
modules.alias file. This means that "virsh nodedev-detach" of a
host device will bind it to its appropriate VFIO variant driver (if
one is available), and also if a <hostdev> decice in a domain
config has "managed='yes'", libvirt will bind it to a variant
driver if possible (in order to force binding to the basic vfio-pci
driver instead, you just need to add the <driver> element mentioned
above).
The first 12 patches are all just getting (1) going (a lot of it is
refactoring code to use common code for the four places that use the
hostdev <driver> element), and the final 3 patches implement (2).
More details are spread along the way.
Differences from V1:
I squashed together a couple of the patches, and fixed some things that caused
CI jobs to fail (I'd forgotten to push the branch to gitlab and
trigger CI).
Laine Stump (15):
util: properly deal with module vs. driver when binding device to
driver
schema: consolidate RNG for all hostdev <driver> elements
conf: move/rename hostdev PCI driver type enum to device_conf.h
conf: normalize hostdev <driver> parsing to simplify adding new attr
conf: put hostdev PCI backend into a struct
conf: use virDeviceHostdevPCIDriverInfo in network and networkport
objects
conf: split out hostdev <driver> parse/format to their own functions
conf: use new common parser/formatter for hostdev driver in network
XML
tests: remove explicit <driver name='vfio'/> from hostdev test cases
xen: explicitly set hostdev driver.type at runtime, not in postparse
conf: replace virHostdevIsVFIODevice with virHostdevIsPCIDevice
conf: support manually specifying VFIO variant driver in <hostdev> XML
util: new function virStringSkipToSpace()
tests: mock virPCIDevice(BindTo|UnbindFrom)Stub with nop functions
qemu: automatically bind to a vfio variant driver, if available
docs/formatdomain.rst | 55 ++-
src/conf/device_conf.c | 75 +++
src/conf/device_conf.h | 27 ++
src/conf/domain_capabilities.c | 2 +-
src/conf/domain_capabilities.h | 2 +-
src/conf/domain_conf.c | 98 +---
src/conf/domain_conf.h | 18 +-
src/conf/network_conf.c | 43 +-
src/conf/network_conf.h | 17 +-
src/conf/schemas/basictypes.rng | 20 +
src/conf/schemas/domaincommon.rng | 173 ++++---
src/conf/schemas/network.rng | 10 +-
src/conf/schemas/networkport.rng | 10 +-
src/conf/virconftypes.h | 2 +
src/conf/virnetworkportdef.c | 22 +-
src/conf/virnetworkportdef.h | 4 +-
src/hypervisor/virhostdev.c | 16 +-
src/hypervisor/virhostdev.h | 2 -
src/libvirt_private.syms | 10 +-
src/libxl/libxl_capabilities.c | 2 +-
src/libxl/libxl_domain.c | 65 ++-
src/libxl/libxl_driver.c | 25 +-
src/network/bridge_driver.c | 2 +-
src/qemu/qemu_capabilities.c | 4 +-
src/qemu/qemu_command.c | 14 +-
src/qemu/qemu_domain.c | 29 +-
src/qemu/qemu_hostdev.c | 2 +-
src/qemu/qemu_hotplug.c | 2 +-
src/qemu/qemu_validate.c | 6 +-
src/security/security_apparmor.c | 2 +-
src/security/security_dac.c | 4 +-
src/security/security_selinux.c | 4 +-
src/security/virt-aa-helper.c | 8 +-
src/util/virpci.c | 438 ++++++++++++++++--
src/util/virpci.h | 3 +
src/util/virstring.c | 17 +
src/util/virstring.h | 1 +
tests/domaincapstest.c | 4 +-
tests/libxlxml2domconfigdata/moredevs-hvm.xml | 1 -
tests/networkxml2xmlin/hostdev-pf-old.xml | 8 +
tests/networkxml2xmlin/hostdev-pf.xml | 2 +-
tests/networkxml2xmlout/hostdev-pf-old.xml | 8 +
tests/networkxml2xmlout/hostdev-pf.xml | 2 +-
tests/networkxml2xmltest.c | 6 +
tests/qemuhotplugmock.c | 15 +
.../qemuhotplug-hostdev-pci.xml | 1 -
.../qemuhotplug-base-live+hostdev-pci.xml | 2 +-
...uhotplug-pseries-base-live+hostdev-pci.xml | 2 +-
tests/qemustatusxml2xmldata/modern-in.xml | 2 +-
.../hostdev-pci-address-unassigned.xml | 4 -
.../hostdev-pci-multifunction.xml | 7 -
.../hostdev-vfio-multidomain.xml | 1 -
.../hostdev-vfio-zpci-autogenerate-fids.xml | 2 -
.../hostdev-vfio-zpci-autogenerate-uids.xml | 2 -
.../hostdev-vfio-zpci-autogenerate.xml | 1 -
.../hostdev-vfio-zpci-boundaries.xml | 2 -
.../hostdev-vfio-zpci-ccw-memballoon.xml | 1 -
.../hostdev-vfio-zpci-duplicate.xml | 2 -
...ostdev-vfio-zpci-invalid-uid-valid-fid.xml | 1 -
.../hostdev-vfio-zpci-multidomain-many.xml | 8 -
.../hostdev-vfio-zpci-set-zero.xml | 1 -
.../hostdev-vfio-zpci-uid-set-zero.xml | 1 -
.../hostdev-vfio-zpci-wrong-arch.xml | 1 -
tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 1 -
.../hostdev-vfio.x86_64-latest.args | 5 +-
tests/qemuxml2argvdata/hostdev-vfio.xml | 19 +-
.../net-hostdev-vfio-multidomain.xml | 1 -
tests/qemuxml2argvdata/net-hostdev-vfio.xml | 1 -
tests/qemuxml2argvdata/pseries-hostdevs-1.xml | 3 -
tests/qemuxml2argvdata/pseries-hostdevs-2.xml | 2 -
tests/qemuxml2argvdata/pseries-hostdevs-3.xml | 2 -
...v-pci-address-unassigned.x86_64-latest.xml | 4 -
...ostdev-pci-multifunction.x86_64-latest.xml | 7 -
...io-zpci-autogenerate-fids.s390x-latest.xml | 2 -
...io-zpci-autogenerate-uids.s390x-latest.xml | 2 -
...ev-vfio-zpci-autogenerate.s390x-latest.xml | 1 -
...tdev-vfio-zpci-boundaries.s390x-latest.xml | 2 -
...-vfio-zpci-ccw-memballoon.s390x-latest.xml | 1 -
...fio-zpci-multidomain-many.s390x-latest.xml | 8 -
.../hostdev-vfio-zpci.s390x-latest.xml | 1 -
.../hostdev-vfio.x86_64-latest.xml | 24 +-
.../net-hostdev-vfio.x86_64-latest.xml | 1 -
.../pseries-hostdevs-1.ppc64-latest.xml | 3 -
.../pseries-hostdevs-2.ppc64-latest.xml | 2 -
.../pseries-hostdevs-3.ppc64-latest.xml | 2 -
tests/virhostdevtest.c | 2 +-
.../plug-hostdev-pci-unmanaged.xml | 2 +-
.../plug-hostdev-pci.xml | 2 +-
tests/xlconfigdata/test-fullvirt-pci.xml | 2 -
tests/xmconfigdata/test-pci-dev-syntax.xml | 2 -
tests/xmconfigdata/test-pci-devs.xml | 2 -
tools/virsh-completer-nodedev.c | 4 +-
92 files changed, 933 insertions(+), 498 deletions(-)
create mode 100644 tests/networkxml2xmlin/hostdev-pf-old.xml
create mode 100644 tests/networkxml2xmlout/hostdev-pf-old.xml
322
days inactive
382
days old
44 comments
3 participants
participants (3)
-
Ján Tomko -
Laine Stump -
Peter Krempa