- Devel - libvirt List Archives

[libvirt] [PATCH] vz: add validation callbacks
by Mikhail Feoktistov 19 Aug '16

19 Aug '16

This patch fixes a bug which occurs when we check a bus and unit number for a new attached disk. We should do this check in ValidadionCallback, not in PostParse callback. Because in PostParse we have not initialized disk->info.addr.drive struct yet. Move part of code from domainPostParseCallback to domainValidateCallback and part from devicesPostParseCallback to deviceValidateCallback. PostParse callbacks are for modification data. ValidateCallbacks are only for checks. --- src/vz/vz_driver.c | 23 +++++++++++++++++++++-- src/vz/vz_utils.c | 2 +- src/vz/vz_utils.h | 2 +- 3 files changed, 23 insertions(+), 4 deletions(-) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index b1b6d14..e9f9a17 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -232,6 +232,7 @@ vzConnectGetCapabilities(virConnectPtr conn) xml = virCapabilitiesFormatXML(privconn->driver->caps); return xml; } + static int vzDomainDefAddDefaultInputDevices(virDomainDefPtr def) { @@ -258,11 +259,19 @@ static int vzDomainDefPostParse(virDomainDefPtr def, virCapsPtr caps ATTRIBUTE_UNUSED, unsigned int parseFlags ATTRIBUTE_UNUSED, - void *opaque) + void *opaque ATTRIBUTE_UNUSED) { if (vzDomainDefAddDefaultInputDevices(def) < 0) return -1; + return 0; +} + +static int +vzDomainDefValidate(const virDomainDef *def, + virCapsPtr caps ATTRIBUTE_UNUSED, + void *opaque) +{ if (vzCheckUnsupportedControllers(def, opaque) < 0) return -1; @@ -284,6 +293,14 @@ vzDomainDeviceDefPostParse(virDomainDeviceDefPtr dev, VIR_STRDUP(dev->data.net->model, "e1000") < 0) return -1; + return 0; +} + +static int +vzDomainDeviceDefValidate(const virDomainDeviceDef *dev, + const virDomainDef *def, + void *opaque ATTRIBUTE_UNUSED) +{ if (dev->type == VIR_DOMAIN_DEVICE_DISK) return vzCheckUnsupportedDisk(def, dev->data.disk, opaque); else if (dev->type == VIR_DOMAIN_DEVICE_GRAPHICS) @@ -299,8 +316,10 @@ static virDomainXMLPrivateDataCallbacks vzDomainXMLPrivateDataCallbacksPtr = { static virDomainDefParserConfig vzDomainDefParserConfig = { .macPrefix = {0x42, 0x1C, 0x00}, - .devicesPostParseCallback = vzDomainDeviceDefPostParse, .domainPostParseCallback = vzDomainDefPostParse, + .devicesPostParseCallback = vzDomainDeviceDefPostParse, + .domainValidateCallback = vzDomainDefValidate, + .deviceValidateCallback = vzDomainDeviceDefValidate, }; static vzDriverPtr diff --git a/src/vz/vz_utils.c b/src/vz/vz_utils.c index 312355d..eaf09f2 100644 --- a/src/vz/vz_utils.c +++ b/src/vz/vz_utils.c @@ -463,7 +463,7 @@ vzCheckUnsupportedDisk(const virDomainDef *def, } int -vzCheckUnsupportedControllers(virDomainDefPtr def, vzCapabilitiesPtr vzCaps) +vzCheckUnsupportedControllers(const virDomainDef *def, vzCapabilitiesPtr vzCaps) { size_t i, j; virDomainControllerDefPtr controller; diff --git a/src/vz/vz_utils.h b/src/vz/vz_utils.h index d033f94..4b407ec 100644 --- a/src/vz/vz_utils.h +++ b/src/vz/vz_utils.h @@ -137,7 +137,7 @@ vzCheckUnsupportedDisk(const virDomainDef *def, virDomainDiskDefPtr disk, vzCapabilitiesPtr vzCaps); int -vzCheckUnsupportedControllers(virDomainDefPtr def, +vzCheckUnsupportedControllers(const virDomainDef *def, vzCapabilitiesPtr vzCaps); int vzGetDefaultSCSIModel(vzDriverPtr driver, -- 1.8.3.1

2 3

[libvirt] [PATCH v2] vz: fixed race in vzDomainAttach/DettachDevice
by Olga Krishtal 19 Aug '16

19 Aug '16

While dettaching/attaching device in OpenStack, nova calls vzDomainDettachDevice twice, because the update of the internal configuration of the ct comes a bit latter than the update event. As the result, we suffer from the second call to dettach the same device. Signed-off-by: Olga Krishtal <okrishtal(a)virtuozzo.com> --- src/vz/vz_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index 2ed12db..26b14a2 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -1193,6 +1193,9 @@ static int vzDomainAttachDeviceFlags(virDomainPtr domain, const char *xml, if (prlsdkAttachDevice(driver, dom, dev) < 0) goto cleanup; + if (prlsdkUpdateDomain(driver, dom) < 0) + goto cleanup; + ret = 0; cleanup: virDomainDeviceDefFree(dev); @@ -1245,6 +1248,9 @@ static int vzDomainDetachDeviceFlags(virDomainPtr domain, const char *xml, if (prlsdkDetachDevice(driver, dom, dev) < 0) goto cleanup; + if (prlsdkUpdateDomain(driver, dom) < 0) + goto cleanup; + ret = 0; cleanup: virDomainDeviceDefFree(dev); -- 1.8.3.1

3 2

[libvirt] [PATCH 0/7] More syntax-check cleanups
by Ján Tomko 18 Aug '16

18 Aug '16

The first patch pulls the latest gnulibs to fetch the newest syntax-check speedups. Patch 2 is included since a gnulib update will trigger configure anyway. The rest are mostly cleanups, the speed-ups they (might) provide are barely measurable. Ján Tomko (7): maint: update to latest gnulib configure.ac: drop checks for ETH flags tests: fix the return value of test-wrap-argv cfg.mk: use subst instead of tr cfg.mk: drop redundant sc_prohibit_gethostby cfg.mk: drop redundant sc_size_of_brackets cfg.mk: join not_streq and not_strneq tests .gnulib | 2 +- build-aux/check-spacing.pl | 2 +- cfg.mk | 35 +++++------------------------------ configure.ac | 5 ----- src/util/virnetdev.c | 20 ++++++++++---------- tests/test-wrap-argv.pl | 2 +- tests/virstoragetest.c | 2 +- 7 files changed, 19 insertions(+), 49 deletions(-) -- 2.7.3

3 15

[libvirt] [PATCH 0/7]
by Nikolay Shirokovskiy 18 Aug '16

18 Aug '16

filesystem pools inception Filesystem pools is a facility to manage filesystems resources similar to how storage pools manages volume resources. Furthermore new API follows storage API closely where it makes sense. Uploading/downloading operations are not defined yet as it is not obvious how to make it properly. I guess we can use some kind of tar to make a stream from a filesystem. Please share you thoughts on this particular issue. The patchset provides 'dir' backend which simply expose directories in some directory in host filesystem. The virsh commands are provided too. So it is ready to play with, just replace 'pool' in xml descriptions and virsh commands to 'fspool' and 'volume' to 'item'. Olga Krishtal (7): fspool: introduce filesystem pools API fspool: usual driver based implementation of filesystem pools API fspools: configuration and internal representation fspools: acl support for filesystem pools remote: filesystem pools driver implementation fspool: default implementation of filesystem pools virsh: filesystem pools commands configure.ac | 33 + daemon/Makefile.am | 4 + daemon/libvirtd.c | 10 + daemon/remote.c | 35 + include/libvirt/libvirt-fs.h | 273 +++++ include/libvirt/libvirt.h | 1 + include/libvirt/virterror.h | 8 + po/POTFILES.in | 6 + src/Makefile.am | 46 + src/access/viraccessdriver.h | 12 + src/access/viraccessdrivernop.c | 19 + src/access/viraccessdriverpolkit.c | 47 + src/access/viraccessdriverstack.c | 49 + src/access/viraccessmanager.c | 31 + src/access/viraccessmanager.h | 11 + src/access/viraccessperm.c | 15 +- src/access/viraccessperm.h | 124 +++ src/conf/fs_conf.c | 1624 +++++++++++++++++++++++++++ src/conf/fs_conf.h | 310 ++++++ src/datatypes.c | 154 +++ src/datatypes.h | 94 ++ src/driver-fs.h | 210 ++++ src/driver.h | 3 + src/fs/fs_backend.h | 85 ++ src/fs/fs_backend_dir.c | 334 ++++++ src/fs/fs_backend_dir.h | 8 + src/fs/fs_driver.c | 2164 ++++++++++++++++++++++++++++++++++++ src/fs/fs_driver.h | 10 + src/libvirt-fs.c | 1715 ++++++++++++++++++++++++++++ src/libvirt.c | 28 + src/libvirt_private.syms | 53 + src/libvirt_public.syms | 46 + src/remote/remote_driver.c | 72 +- src/remote/remote_protocol.x | 522 ++++++++- src/rpc/gendispatch.pl | 19 +- src/util/virerror.c | 37 + tools/Makefile.am | 4 + tools/virsh-fspool.c | 1728 ++++++++++++++++++++++++++++ tools/virsh-fspool.h | 36 + tools/virsh-item.c | 1274 +++++++++++++++++++++ tools/virsh-item.h | 37 + tools/virsh.c | 4 + tools/virsh.h | 9 + 43 files changed, 11294 insertions(+), 10 deletions(-) create mode 100644 include/libvirt/libvirt-fs.h create mode 100644 src/conf/fs_conf.c create mode 100644 src/conf/fs_conf.h create mode 100644 src/driver-fs.h create mode 100644 src/fs/fs_backend.h create mode 100644 src/fs/fs_backend_dir.c create mode 100644 src/fs/fs_backend_dir.h create mode 100644 src/fs/fs_driver.c create mode 100644 src/fs/fs_driver.h create mode 100644 src/libvirt-fs.c create mode 100644 tools/virsh-fspool.c create mode 100644 tools/virsh-fspool.h create mode 100644 tools/virsh-item.c create mode 100644 tools/virsh-item.h -- 1.8.3.1

2 8

[libvirt] [PATCH v1 00/19] Implementation of QEMU vhost-scsi
by Eric Farman 18 Aug '16

18 Aug '16

This patch series provides a libvirt implementation of the vhost-scsi interface in QEMU. As near as I can see, this was discussed upstream in July 2014[1], and ended in a desire to replace a vhost-scsi controller in favor of a hostdev element instead[2]. There is no capability check in this series for vhost-scsi in the underlying QEMU. Using a recent QEMU built with --disable-vhost-scsi fails with "not a valid device model name." Host Filesystem Example: # ls /sys/kernel/config/target/vhost/ discovery_auth naa.5001405df3e54061 version # ls /sys/kernel/config/target/vhost/naa.5001405df3e54061/tpgt_1/lun/ lun_0 QEMU Example (snippet): -device vhost-scsi-ccw,wwpn=naa.5001405df3e54061,devno=fe.0.1000 Libvirt Example (snippet): <hostdev mode='subsystem' type='scsi'> <source protocol='vhost' wwpn='naa.5001405df3e54061'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x1000'/> </hostdev> Guest Viewpoint: # lsscsi [1:0:1:0] disk LIO-ORG disk0 4.0 /dev/sda # dmesg | grep 1: [ 6.065735] scsi host1: Virtio SCSI HBA [ 6.093892] scsi 1:0:1:0: Direct-Access LIO-ORG disk0 4.0 PQ: 0 ANSI: 5 [ 6.313615] sd 1:0:1:0: Attached scsi generic sg0 type 0 [ 6.314981] sd 1:0:1:0: [sda] 29360128 512-byte logical blocks: (15.0 GB/14.0 GiB) [ 6.317290] sd 1:0:1:0: [sda] Write Protect is off [ 6.317566] sd 1:0:1:0: [sda] Mode Sense: 43 00 10 08 [ 6.317853] sd 1:0:1:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 6.352722] sd 1:0:1:0: [sda] Attached SCSI disk [1] http://www.redhat.com/archives/libvir-list/2014-July/msg01235.html [2] http://www.redhat.com/archives/libvir-list/2014-July/msg01390.html Eric Farman (19): conf: Add definitions for "vhost" protocol in hostdev tags util: Allow a vhost protocol for scsi hostdev security: Allow a vhost protocol for scsi hostdev qemu: Refactor qemuIsSharedHostdev for readability/extendability qemu: Allow a vhost protocol for scsi hostdev conf: Parse vhost-scsi XML tag conf: Prevent use of shareable on vhost-scsi devices qemu: Introduce vhost-scsi capability qemu: Refactor qemuBuildHostdevCommandLine for non-vhost devices qemu: Add vhost-scsi string for -device parameter qemu: Add vhost-scsi to hostdev schema docs: Add vhost-scsi to documentation qemu: Refactor hotplug in preparation for vhost-scsi qemu: Allow hotplug of vhost-scsi device conf: Create vhost-scsi hostdev protocol in dumpxml conf: Set up vhost-scsi hostdev to self-close source tag tests: Introduce basic vhost-scsi test conf: Do not create a virtio-scsi controller for vhost-scsi hostdev qemu: Allow the specification of a vhost-scsi devno docs/formatdomain.html.in | 16 +++ docs/schemas/domaincommon.rng | 12 +++ src/conf/domain_conf.c | 94 ++++++++++++++-- src/conf/domain_conf.h | 8 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 5 + src/qemu/qemu_command.c | 120 +++++++++++++++++++-- src/qemu/qemu_command.h | 6 ++ src/qemu/qemu_conf.c | 21 +++- src/qemu/qemu_domain_address.c | 10 ++ src/qemu/qemu_hotplug.c | 76 +++++++++---- src/qemu/qemu_monitor.c | 21 ++++ src/qemu/qemu_monitor.h | 4 + src/security/security_apparmor.c | 5 +- src/security/security_dac.c | 10 +- src/security/security_selinux.c | 10 +- src/util/virhostdev.c | 13 ++- src/util/virscsi.c | 26 +++++ src/util/virscsi.h | 1 + tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + .../qemuxml2argv-hostdev-scsi-vhost-scsi.args | 24 +++++ .../qemuxml2argv-hostdev-scsi-vhost-scsi.xml | 33 ++++++ tests/qemuxml2argvmock.c | 12 +++ tests/qemuxml2argvtest.c | 3 + 35 files changed, 486 insertions(+), 58 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-vhost-scsi.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-vhost-scsi.xml -- 1.9.1

3 42

[libvirt] [PATCHv3 00/11] qemu: allow disabling certain virtio revisions
by Ján Tomko 18 Aug '16

18 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1227354 v1: https://www.redhat.com/archives/libvir-list/2016-July/msg01235.html v2: https://www.redhat.com/archives/libvir-list/2016-August/msg00412.html * probe for the qemu capability * add the attribute to virtio1-only devices such as virtio-gpu and virtio-input devices * allow multiple revisions to be specified v3: * touch up documentation * rename the capability from "virtio-revision" to "virtio-disable-legacy" * move the formatting in qemuBuildNicDevStr after the address and only do it for virtio * get rid of novelty enum names I left the bitmap usage intact, since enforcing both revision makes sense according to the discussion under: [PATCH 0/6] Use more PCIe, less legacy PCI slots and I considered specifying both features in the XML nicer than adding a new value. Ján Tomko (11): Use separate buffer for <input> subelements Add virtio revision attribute to memballoon Add virtio revision attribute to disks Add virtio revision attribute to controllers Add virtio revision attribute to filesystems Add virtio revision attribute to interfaces Add virtio revision to rng devices Add virtio revision attribute to video Add virtio revision attribute to input devices Introduce QEMU_CAPS_VIRTIO_DISABLE_LEGACY qemu: format options for enforcing virtio revisions docs/formatdomain.html.in | 69 ++++++++++ docs/schemas/domaincommon.rng | 37 ++++++ src/conf/domain_conf.c | 148 +++++++++++++++++++-- src/conf/domain_conf.h | 16 +++ src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 56 ++++++++ tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + .../qemuxml2argv-virtio-revision.args | 62 +++++++++ .../qemuxml2argv-virtio-revision.xml | 113 ++++++++++++++++ tests/qemuxml2argvtest.c | 11 ++ .../qemuxml2xmlout-virtio-revision.xml | 113 ++++++++++++++++ tests/qemuxml2xmltest.c | 2 + 19 files changed, 630 insertions(+), 11 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-revision.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-revision.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-revision.xml -- 2.7.3

6 27

[libvirt] Fixing backwards migration with usb-ccid devices
by Ján Tomko 18 Aug '16

18 Aug '16

Dear list, my USB address assignment code (released in 2.1.0) incorrectly assumed that older libvirt allows specifying USB addresses for all usb devices: https://bugzilla.redhat.com/show_bug.cgi?id=1360963 For usb-ccid devices, this is only possible since commit 2dabe2e0 (Released in libvirt 1.3.3 this April). Before that, we required either a PCI address or no address for all controllers, a USB address will be rejected by the XML parser. The only reliable way to fix this that I could think of is: not to assign addresses to domains which might need to be migrated backwards. This is doable downstream where we can make assumptions on the version of libvirt based on the machine type, but that won't work upstream. I have considered dropping just the USB address of the CCID controller from the XML if we do not know that we are migrating to a new enough libvirt (that would be 2.2.0 since it would need a new driver flag and migration flag), but that would only fix it for cases where the address generated by libvirt matches the one that QEMU will give it. But if it does not, migration to libvirt 1.3.3 to 2.1.0 will be broken. Do you have any ideas how this might be fixed (other than reverting the assignment), or is this something that downstreams have to deal with? Jan

1 0

[libvirt] [PATCH v2] qemu: Fix crash hot plugging luks volume
by John Ferlan 18 Aug '16

18 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1367259 Crash occurs because 'secrets' is being dereferenced in call: if (qemuDomainSecretSetup(conn, priv, secinfo, disk->info.alias, VIR_SECRET_USAGE_TYPE_VOLUME, NULL, &src->encryption->secrets[0]->seclookupdef, true) < 0) (gdb) p *src->encryption $1 = {format = 2, nsecrets = 0, secrets = 0x0, encinfo = {cipher_size = 0, cipher_name = 0x0, cipher_mode = 0x0, cipher_hash = 0x0, ivgen_name = 0x0, ivgen_hash = 0x0}} (gdb) bt priv=priv@entry=0x7fffc03be160, disk=disk@entry=0x7fffb4002ae0) at qemu/qemu_domain.c:1087 disk=0x7fffb4002ae0, vm=0x7fffc03a2580, driver=0x7fffc02ca390, conn=0x7fffb00009a0) at qemu/qemu_hotplug.c:355 Upon entry to qemuDomainAttachVirtioDiskDevice, src->encryption points at a valid 'secret' buffer w/ nsecrets == 1; however, the call to qemuDomainDetermineDiskChain will call virStorageFileGetMetadata and eventually virStorageFileGetMetadataInternal where the src->encryption was overwritten when probing the volume. Commit id 'a48c7141' added code to virStorageFileGetMetadataInternal to determine if the disk/volume would use/need encryption and allocated a meta->encryption. This overwrote an existing encryption buffer already provided by the XML This patch adds a check for meta->encryption already present before just allocating and overwriting an existing buffer. It then checks the existing encryption data to ensure the XML provided format for the disk matches the expected format read from the disk and errors if there is a mismatch. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- v1: http://www.redhat.com/archives/libvir-list/2016-August/msg00805.html Tested w/ delete luks volume, create luks volume, dump luks volume, attach to guest, detach from guest, and repeat... src/util/virstoragefile.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 471aa1f..feeb061 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -950,10 +950,21 @@ virStorageFileGetMetadataInternal(virStorageSourcePtr meta, for (i = 0; fileTypeInfo[meta->format].cryptInfo[i].format != 0; i++) { if (virStorageFileHasEncryptionFormat(&fileTypeInfo[meta->format].cryptInfo[i], buf, len)) { - if (VIR_ALLOC(meta->encryption) < 0) - goto cleanup; - - meta->encryption->format = fileTypeInfo[meta->format].cryptInfo[i].format; + int expt_fmt = fileTypeInfo[meta->format].cryptInfo[i].format; + if (!meta->encryption) { + if (VIR_ALLOC(meta->encryption) < 0) + goto cleanup; + + meta->encryption->format = expt_fmt; + } else { + if (meta->encryption->format != expt_fmt) { + virReportError(VIR_ERR_XML_ERROR, + _("encryption format %d doesn't match " + "expected format %d"), + meta->encryption->format, expt_fmt); + goto cleanup; + } + } } } } -- 2.7.4

1 0

[libvirt] [PATCH] qemu: Fix crash hot plugging luks volume
by John Ferlan 18 Aug '16

18 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1367259 Crash occurs because 'secrets' is being dereferenced in call: if (qemuDomainSecretSetup(conn, priv, secinfo, disk->info.alias, VIR_SECRET_USAGE_TYPE_VOLUME, NULL, &src->encryption->secrets[0]->seclookupdef, true) < 0) (gdb) p *src->encryption $1 = {format = 2, nsecrets = 0, secrets = 0x0, encinfo = {cipher_size = 0, cipher_name = 0x0, cipher_mode = 0x0, cipher_hash = 0x0, ivgen_name = 0x0, ivgen_hash = 0x0}} (gdb) bt priv=priv@entry=0x7fffc03be160, disk=disk@entry=0x7fffb4002ae0) at qemu/qemu_domain.c:1087 disk=0x7fffb4002ae0, vm=0x7fffc03a2580, driver=0x7fffc02ca390, conn=0x7fffb00009a0) at qemu/qemu_hotplug.c:355 Upon entry to qemuDomainAttachVirtioDiskDevice, src->encryption points at a valid 'secret' buffer w/ nsecrets == 1; however, the call to qemuDomainDetermineDiskChain will call virStorageFileGetMetadata and eventually virStorageFileGetMetadataInternal where the src->encryption was overwritten when probing the volume. Commit id 'a48c7141' added code to virStorageFileGetMetadataInternal to determine if the disk/volume would use/need encryption and allocated a meta->encryption. This overwrote an existing encryption buffer already provided by the XML This patch adds an argument to virStorageFileGetMetadataInternal in order to avoid the encryption probe of the volume. This will only be be set to true for the storage volume buffer/fd parsing. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- NB: This I believe the bare bones that could be done. If desired, I could also modify virStorageFileGetMetadata[Recurse] and all the callers in order to specifically add a 'probe_encryption' variable there as well. For this path, the "root" callers would add the 'false', hence the reason I chose to just modify the *Recurse function to pass 'false'. I have tested creating a luks volume and of course hot plugging with this patch... src/storage/storage_driver.c | 2 +- src/util/virstoragefile.c | 8 +++++--- src/util/virstoragefile.h | 3 ++- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 6f1e372..fe0e164 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -3239,7 +3239,7 @@ virStorageFileGetMetadataRecurse(virStorageSourcePtr src, &buf)) < 0) goto cleanup; - if (virStorageFileGetMetadataInternal(src, buf, headerLen, + if (virStorageFileGetMetadataInternal(src, buf, headerLen, false, &backingFormat) < 0) goto cleanup; diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 471aa1f..4b6bde3 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -928,6 +928,7 @@ int virStorageFileGetMetadataInternal(virStorageSourcePtr meta, char *buf, size_t len, + bool probe_encryption, int *backingFormat) { int ret = -1; @@ -946,7 +947,7 @@ virStorageFileGetMetadataInternal(virStorageSourcePtr meta, goto cleanup; } - if (fileTypeInfo[meta->format].cryptInfo != NULL) { + if (probe_encryption && fileTypeInfo[meta->format].cryptInfo != NULL) { for (i = 0; fileTypeInfo[meta->format].cryptInfo[i].format != 0; i++) { if (virStorageFileHasEncryptionFormat(&fileTypeInfo[meta->format].cryptInfo[i], buf, len)) { @@ -1129,7 +1130,7 @@ virStorageFileGetMetadataFromBuf(const char *path, if (!(ret = virStorageFileMetadataNew(path, format))) return NULL; - if (virStorageFileGetMetadataInternal(ret, buf, len, + if (virStorageFileGetMetadataInternal(ret, buf, len, true, backingFormat) < 0) { virStorageSourceFree(ret); return NULL; @@ -1200,7 +1201,8 @@ virStorageFileGetMetadataFromFD(const char *path, goto cleanup; } - if (virStorageFileGetMetadataInternal(meta, buf, len, backingFormat) < 0) + if (virStorageFileGetMetadataInternal(meta, buf, len, true, + backingFormat) < 0) goto cleanup; if (S_ISREG(sb.st_mode)) diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h index 3d09468..bb71372 100644 --- a/src/util/virstoragefile.h +++ b/src/util/virstoragefile.h @@ -289,8 +289,9 @@ int virStorageFileProbeFormatFromBuf(const char *path, int virStorageFileGetMetadataInternal(virStorageSourcePtr meta, char *buf, size_t len, + bool probe_encryption, int *backingFormat) - ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(4); + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(5); virStorageSourcePtr virStorageFileGetMetadataFromFD(const char *path, int fd, -- 2.7.4

2 3

[libvirt] [PATCH v2 0/4] Use more PCIe, less legacy PCI slots
by Laine Stump 17 Aug '16

17 Aug '16

Due to its unpopularity, I've removed the "hotpluggable" attribute that was in V1 of this patchset, and also auto-assign *all* devices (except primary video and USB2 for historical reasons) to hotpluggable slots only (rather than assigning devices to the non-hotpluggable pcie-root if libvirt doesn't currently allow hotplugging those devices). So these patches have *NO* new configuration - they are just correcting bad (or at least suboptimal) behavior, and should thus be reasonably uncontroversial :-) The first patch corrects an error in where pci-bridge can be plugged in, which isn't really about using more PCI, but *is* about getting devices plugged into the right kind of slots. (tl;dr - a pci-bridge works when plugged into pcie-root, but people who know about PCI tell me that it's "not proper" to do so, so now we don't unless specifically told to). Patch 2 puts virtio devices into PCIe slots when they support it, patch 3 puts the new e1000e network device (which is a PCIe version of the Intel e1000) into a PCIe slot (as long as the machine has PCIe), and patch 3 does the same for the NEC xhci USB3 controller - all of these devices present as PCie devices when in a PCIe slot, and as PCI devices otherwise, and there is no doubt that preferring PCIe is desirable (legacy PCI controllers only exist on Q35 and other PCIe-capable machinetypes as a crutch to use when you have to use a device that is legacy-PCI-only). One exception that isn't handled in this series is that when a virtio device has --disable-modern=on, it will always be a PCI device. Since Jan's patches to support setting that option aren't in yet, I don't do anything about it. Another caveat - since the auto-adding of PCI controllers will currently only add pci-bridge devices, in order for these patches to be useful, you'll need to manually add a <controller type='pci' model='pcie-root-port'/> for each device. Before pushing these patches, I plan to add another patch that auto-adds pcie-*-port as needed, but wanted to post what I have now to get a head start on reviews (especially since many reviewers will be at KVM Forum next week). Finally, if you want to try out these patches, you'll need to apply them on top of jtomko's patch "Introduce QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY", from the most recent version of his virtio version patches. Laine Stump (4): conf: restrict what type of buses will accept a pci-bridge qemu: assign virtio devices to PCIe slot when appropriate qemu: assign e1000e network devices to PCIe controllers when appropriate qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate src/conf/domain_addr.c | 29 +++- src/conf/domain_addr.h | 4 +- src/qemu/qemu_domain_address.c | 69 ++++++++-- tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 10 +- tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args | 58 ++++++++ tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml | 67 +++++++++ .../qemuxml2argv-q35-virtio-pci.args | 58 ++++++++ .../qemuxml2argv-q35-virtio-pci.xml | 67 +++++++++ .../qemuxml2argv-q35-virtio-pcie.args | 56 ++++++++ tests/qemuxml2argvtest.c | 45 +++++- .../qemuxml2xmlout-autoindex.xml | 10 +- .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 152 +++++++++++++++++++++ .../qemuxml2xmlout-q35-virtio-pci.xml | 152 +++++++++++++++++++++ tests/qemuxml2xmltest.c | 40 ++++++ 14 files changed, 788 insertions(+), 29 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pcie.args create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virtio-pci.xml -- 2.7.4

2 10