- Devel - libvirt List Archives

[libvirt PATCH 0/2] qemu: changes to use feature=on|off syntax for -cpu unconditionally
by Daniel P. Berrangé 07 Oct '21

07 Oct '21

Given our min QEMU, it doesn't seem like we need to support either the old "-feature" / "+feature" syntax, nor the bare "feature" syntax. Daniel P. Berrangé (2): qemu: remove use of (+|-)name syntax for -cpu featres qemu: remove use of implicit boolean syntax for -cpu features src/qemu/qemu_command.c | 38 ++++++------------- .../clock-timer-hyperv-rtc.args | 2 +- tests/qemuxml2argvdata/cpu-Haswell2.args | 2 +- tests/qemuxml2argvdata/cpu-Haswell3.args | 2 +- .../qemuxml2argvdata/cpu-cache-disable3.args | 2 +- .../cpu-check-default-partial.args | 2 +- tests/qemuxml2argvdata/cpu-eoi-disabled.args | 2 +- tests/qemuxml2argvdata/cpu-eoi-enabled.args | 2 +- tests/qemuxml2argvdata/cpu-exact1.args | 2 +- .../cpu-exact2-nofallback.args | 2 +- tests/qemuxml2argvdata/cpu-exact2.args | 2 +- tests/qemuxml2argvdata/cpu-fallback.args | 2 +- tests/qemuxml2argvdata/cpu-host-kvmclock.args | 2 +- .../qemuxml2argvdata/cpu-host-model-cmt.args | 2 +- .../cpu-host-model-fallback.args | 2 +- .../cpu-host-model-vendor.args | 2 +- tests/qemuxml2argvdata/cpu-host-model.args | 2 +- .../cpu-host-model.x86_64-4.1.0.args | 2 +- .../cpu-host-model.x86_64-4.2.0.args | 2 +- .../cpu-host-model.x86_64-5.0.0.args | 2 +- .../cpu-host-model.x86_64-5.1.0.args | 2 +- .../cpu-host-model.x86_64-5.2.0.args | 2 +- .../cpu-host-model.x86_64-6.0.0.args | 2 +- .../cpu-host-model.x86_64-6.1.0.args | 2 +- .../cpu-host-model.x86_64-latest.args | 2 +- .../cpu-host-passthrough-features.args | 2 +- tests/qemuxml2argvdata/cpu-kvmclock.args | 2 +- tests/qemuxml2argvdata/cpu-minimum1.args | 2 +- tests/qemuxml2argvdata/cpu-minimum2.args | 2 +- tests/qemuxml2argvdata/cpu-strict1.args | 2 +- .../cpu-translation.x86_64-latest.args | 2 +- tests/qemuxml2argvdata/cpu-tsc-frequency.args | 2 +- .../eoi-disabled.x86_64-latest.args | 2 +- .../eoi-enabled.x86_64-latest.args | 2 +- .../graphics-spice-timeout.args | 2 +- .../hyperv-stimer-direct.x86_64-latest.args | 2 +- .../qemuxml2argvdata/hyperv.x86_64-4.0.0.args | 2 +- .../hyperv.x86_64-latest.args | 2 +- .../kvmclock+eoi-disabled.x86_64-latest.args | 2 +- tests/qemuxml2argvdata/kvmclock.args | 2 +- .../pci-bridge-many-disks.args | 2 +- .../pv-spinlock-disabled.x86_64-latest.args | 2 +- .../pv-spinlock-enabled.x86_64-latest.args | 2 +- 43 files changed, 54 insertions(+), 68 deletions(-) -- 2.31.1

2 5

[libvirt PATCHv2 0/5] qemu: implement virtiofs hot(un)plug (virtiofs epopee)
by Ján Tomko 07 Oct '21

07 Oct '21

diff to v1 * do not store logCtxt in private data * qemuDomainGetVHostUserChrSourceDef inlined in the only function that uses it * a new connection to the logManager is opened when virtiofsd is started * use VIR_APPEND_ELEMENT_COPY to reuse 'fs' on the successful audit * qemuDomainRemoveFSDevice only processes virtiofs devices now Ján Tomko (5): logging: define cleanup func for virLogManager qemu: virtiofs: open a separate connection to virtlogd qemu: Revert "qemuExtDevicesStart: pass logManager" qemu: implement virtiofs hotplug qemu: implement virtiofs hotunplug src/conf/domain_conf.c | 24 +++++ src/conf/domain_conf.h | 2 + src/libvirt_private.syms | 1 + src/logging/log_manager.h | 2 + src/qemu/qemu_driver.c | 9 +- src/qemu/qemu_extdevice.c | 3 +- src/qemu/qemu_extdevice.h | 1 - src/qemu/qemu_hotplug.c | 186 +++++++++++++++++++++++++++++++++++++- src/qemu/qemu_process.c | 4 +- src/qemu/qemu_virtiofs.c | 8 +- src/qemu/qemu_virtiofs.h | 3 +- 11 files changed, 230 insertions(+), 13 deletions(-) -- 2.31.1

2 10

[PATCH] tools: Fix typo firemare -> firmware
by Andrea Bolognani 06 Oct '21

06 Oct '21

Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as trivial. tools/virt-host-validate-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virt-host-validate-common.c b/tools/virt-host-validate-common.c index 556223242d..7a5cda4104 100644 --- a/tools/virt-host-validate-common.c +++ b/tools/virt-host-validate-common.c @@ -515,7 +515,7 @@ int virHostValidateSecureGuests(const char *hvname, } else { virHostMsgFail(level, "AMD Secure Encrypted Virtualization appears to be " - "disabled in firemare."); + "disabled in firmware."); return VIR_HOST_VALIDATE_FAILURE(level); } } -- 2.31.1

2 1

[PATCH 00/11] qdev: Add JSON -device and fix QMP device_add
by Kevin Wolf 06 Oct '21

06 Oct '21

It's still a long way until we'll have QAPIfied devices, but there are some improvements that we can already make now to make the future switch easier. One important part of this is having code paths without QemuOpts, which we want to get rid of and replace with the keyval parser in the long run. This series adds support for JSON syntax to -device, which bypasses QemuOpts. While we're not using QAPI yet, devices are based on QOM, so we already do have type checks and an implied schema. JSON syntax supported now can be supported by QAPI later and regarding command line compatibility, actually switching to it becomes an implementation detail this way (of course, it will still add valuable user-visible features like introspection and documentation). Apart from making things more future proof, this also immediately adds a way to do non-scalar properties on the command line. nvme could have used list support recently, and the lack of it in -device led to some rather unnatural solution in the first version (doing the relationship between a device and objects backwards) and loss of features in the following. With this series, using a list as a device property should be possible without any weird tricks. Unfortunately, even QMP device_add goes through QemuOpts before this series, which destroys any type safety QOM provides and also can't support non-scalar properties. This is a bug that is fixed during this series, but that is technically an incompatible change. A similar change was made for netdev_add in commit db2a380c84. libvirt needs to make sure that it actually always passes the right type, because passing a wrong type will start to fail after this series. I hope that libvirt already does things correctly, so this won't cause any trouble, but if it does, there is the option of using the QemuOpts-less code path only for JSON -device and going through a deprecation period for QMP device_add. Kevin Wolf (11): qom: Reduce use of error_propagate() iotests/245: Fix type for iothread property iotests/051: Fix typo qdev: Avoid using string visitor for properties qdev: Make DeviceState.id independent of QemuOpts qdev: Add Error parameter to qdev_set_id() qemu-option: Allow deleting opts during qemu_opts_foreach() qdev: Base object creation on QDict rather than QemuOpts qdev: Avoid QemuOpts in QMP device_add vl: Enable JSON syntax for -device Deprecate stable non-JSON -device and -object qapi/qdev.json | 15 +++-- docs/about/deprecated.rst | 11 ++++ include/hw/qdev-core.h | 10 ++-- include/monitor/qdev.h | 2 +- hw/arm/virt.c | 2 +- hw/core/qdev.c | 6 +- hw/net/virtio-net.c | 4 +- hw/pci-bridge/pci_expander_bridge.c | 2 +- hw/ppc/e500.c | 2 +- hw/vfio/pci.c | 4 +- hw/xen/xen-legacy-backend.c | 3 +- qom/object.c | 7 +-- qom/object_interfaces.c | 17 ++---- softmmu/qdev-monitor.c | 90 +++++++++++++++++------------ softmmu/vl.c | 58 ++++++++++++++++--- util/qemu-option.c | 4 +- tests/qemu-iotests/051 | 2 +- tests/qemu-iotests/051.pc.out | 4 +- tests/qemu-iotests/245 | 4 +- 19 files changed, 161 insertions(+), 86 deletions(-) -- 2.31.1

11 48

[PATCH v2 0/5] Add support for librbd encryption
by Or Ozeri 06 Oct '21

06 Oct '21

Changes from v1: addressed (hopefully) all of Peter's v1 comments (thanks Peter!) Or Ozeri (5): qemu: add disk post parse to qemublocktest qemu: add rbd encryption capability probing conf: add luks2 encryption format conf: add encryption engine property qemu: add librbd encryption engine docs/formatstorageencryption.html.in | 8 +- docs/schemas/domainbackup.rng | 7 + docs/schemas/storagecommon.rng | 9 + src/conf/storage_encryption_conf.c | 33 +++- src/conf/storage_encryption_conf.h | 11 ++ src/qemu/qemu_block.c | 33 ++++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 37 +++- src/qemu/qemu_domain.h | 4 + tests/qemublocktest.c | 3 + .../caps_6.1.0.x86_64.xml | 1 + tests/qemustatusxml2xmldata/upgrade-out.xml | 6 +- ...sk-network-rbd-encryption.x86_64-6.0.0.err | 1 + ...-network-rbd-encryption.x86_64-latest.args | 49 ++++++ .../disk-network-rbd-encryption.xml | 75 +++++++++ tests/qemuxml2argvtest.c | 2 + ...k-network-rbd-encryption.x86_64-latest.xml | 83 +++++++++ tests/qemuxml2xmloutdata/disk-nvme.xml | 65 ++++++- .../disk-slices.x86_64-latest.xml | 4 +- .../encrypted-disk-usage.xml | 38 ++++- tests/qemuxml2xmloutdata/encrypted-disk.xml | 2 +- .../luks-disks-source-qcow2.x86_64-latest.xml | 14 +- .../qemuxml2xmloutdata/luks-disks-source.xml | 10 +- tests/qemuxml2xmloutdata/luks-disks.xml | 47 +++++- tests/qemuxml2xmloutdata/user-aliases.xml | 159 +++++++++++++++++- tests/qemuxml2xmltest.c | 1 + 27 files changed, 678 insertions(+), 27 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-encryption.x86_64-6.0.0.err create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-encryption.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/disk-network-rbd-encryption.xml create mode 100644 tests/qemuxml2xmloutdata/disk-network-rbd-encryption.x86_64-latest.xml mode change 120000 => 100644 tests/qemuxml2xmloutdata/disk-nvme.xml mode change 120000 => 100644 tests/qemuxml2xmloutdata/encrypted-disk-usage.xml mode change 120000 => 100644 tests/qemuxml2xmloutdata/luks-disks.xml mode change 120000 => 100644 tests/qemuxml2xmloutdata/user-aliases.xml -- 2.25.1

3 10

[PATCH] tools: Fix virt-host-validate SEV detection
by Jim Fehlig 06 Oct '21

06 Oct '21

virt-host-validate checks if AMD SEV is enabled by verifying /sys/module/kvm_amd/parameters/sev is set to '1'. On a system running kernel 5.13, the parameter is reported as 'Y'. To be extra paranoid, add a check for 'y' along with 'Y' to complement the existing check for '1'. Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1188715 Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- tools/virt-host-validate-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virt-host-validate-common.c b/tools/virt-host-validate-common.c index 556223242d..ba7f54b4ce 100644 --- a/tools/virt-host-validate-common.c +++ b/tools/virt-host-validate-common.c @@ -501,7 +501,7 @@ int virHostValidateSecureGuests(const char *hvname, return VIR_HOST_VALIDATE_FAILURE(level); } - if (mod_value[0] != '1') { + if (mod_value[0] != '1' && mod_value[0] != 'Y' && mod_value[0] != 'y') { virHostMsgFail(level, "AMD Secure Encrypted Virtualization appears to be " "disabled in kernel. Add kvm_amd.sev=1 " -- 2.33.0

2 1

[libvirt PATCH 00/16] qemu: implement virtiofs hot(un)plug (virtiofs epopee)
by Ján Tomko 06 Oct '21

06 Oct '21

https://bugzilla.redhat.com/show_bug.cgi?id=1897708 Ján Tomko (16): qemu: vhost-user-fs: format alias on the command line conf: define cleanup func for virDomainChrSourceDef qemu: domain: introduce qemuDomainGetVHostUserFSSocketPath qemu: domain: introduce qemuDomainGetVHostUserChrSourceDef tests: qemuxml2argvtest: fix path to virtiofs socket qemu: vhost-user-fs: separate building of chardev string qemu: vhost-user-fs: separate building of device string qemu: do not put virtiofs socket in private data qemu: remove private data from virDomainFSDef qemu: alias: prepare qemuAssignDeviceFSAlias for disjunct ranges qemu: vhost-user-fs: build extdevice for zpci qemu: export vhost-user-fs-related functions qemu: store logCtxt in domain private data qemu: use priv->logCtxt in qemuProcessLaunch qemu: implement virtiofs hotplug qemu: implement virtiofs hotunplug src/conf/domain_conf.c | 24 +++ src/conf/domain_conf.h | 4 + src/libvirt_private.syms | 1 + src/qemu/qemu_alias.c | 20 +- src/qemu/qemu_alias.h | 4 + src/qemu/qemu_command.c | 81 +++++--- src/qemu/qemu_command.h | 6 + src/qemu/qemu_domain.c | 64 +++---- src/qemu/qemu_domain.h | 30 +-- src/qemu/qemu_driver.c | 9 +- src/qemu/qemu_extdevice.c | 6 +- src/qemu/qemu_hotplug.c | 177 +++++++++++++++++- src/qemu/qemu_hotplug.h | 4 + src/qemu/qemu_process.c | 21 ++- src/qemu/qemu_virtiofs.c | 14 +- ...vhost-user-fs-fd-memory.x86_64-latest.args | 4 +- ...vhost-user-fs-hugepages.x86_64-latest.args | 4 +- tests/qemuxml2argvtest.c | 12 -- 18 files changed, 360 insertions(+), 125 deletions(-) -- 2.31.1

2 37

[PATCH 0/8] virsh: Use g_autoptr() for public types
by Michal Privoznik 05 Oct '21

05 Oct '21

In this patchset I'm switching from virXXXFree to g_autoptr(). There are still some left, but very rare occurrence: libvirt.git $ git grep -o "vir[A-Z].*Free" -- tools/ | \ cut -d':' -f 2 | sort | uniq -c | sort -n And of course, after these some functions could use subsequent cleanup, e.g. because cleanup label collapsed to just return statement. But I leave those for future work. Michal Prívozník (8): virsh-util.h: Fix ordering of virshXXXFree functions virsh: Add wrapper for virInterfaceFree virsh: Add wrapper for virStoragePoolFree virsh: Add wrapper for virStorageVolFree virsh: Add wrapper for virNetworkFree virsh: Add wrapper for virNodeDeviceFree virsh: Add wrapper for virNWFilterFree virsh: Add wrapper for virStreamFree build-aux/syntax-check.mk | 4 +- tools/virsh-completer-interface.c | 3 +- tools/virsh-completer-network.c | 8 +-- tools/virsh-completer-nodedev.c | 3 +- tools/virsh-completer-nwfilter.c | 3 +- tools/virsh-completer-pool.c | 3 +- tools/virsh-completer-volume.c | 8 +-- tools/virsh-console.c | 8 +-- tools/virsh-domain.c | 10 +-- tools/virsh-interface.c | 55 +++++---------- tools/virsh-network.c | 75 ++++++-------------- tools/virsh-nodedev.c | 49 ++++---------- tools/virsh-nwfilter.c | 22 ++---- tools/virsh-pool.c | 67 ++++++------------ tools/virsh-util.c | 78 +++++++++++++++++++++ tools/virsh-util.h | 46 +++++++++++-- tools/virsh-volume.c | 109 ++++++++---------------------- 17 files changed, 254 insertions(+), 297 deletions(-) -- 2.32.0

2 9

[libvirt PATCH v3 0/9] Automatic mutex management
by Tim Wiederhake 05 Oct '21

05 Oct '21

V1: https://listman.redhat.com/archives/libvir-list/2021-August/msg00823.html V2: https://listman.redhat.com/archives/libvir-list/2021-September/msg00249.html Changes since V2: * Dropped VIR_XPATH_NODE_AUTORESTORE simplification. Moved to a separate series. * Dropped the attempt to work around g_auto* / clang unused variable warnings (See https://bugs.llvm.org/show_bug.cgi?id=3888, https://bugs.llvm.org/show_bug.cgi?id=43482, and https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2272) Instead, introduce VIR_LOCK_GUARD macro that adds G_GNUC_UNUSED. Regards, Tim Tim Wiederhake (9): internal: Add CONCAT macro virthread: Introduce virLockGuard virthread: Introduce VIR_WITH_MUTEX_LOCK_GUARD virobject: Introduce virObjectLockGuard virobject: Introduce VIR_WITH_OBJECT_LOCK_GUARD virChrdevFDStreamCloseCb: Use virLockGuardNew virChrdevFree: Use VIR_WITH_MUTEX_LOCK bhyveAutostartDomain: Use virObjectLockGuard lxcDomainDetachDeviceHostdevUSBLive: Use VIR_WITH_OBJECT_LOCK_GUARD src/bhyve/bhyve_driver.c | 4 ++-- src/conf/virchrdev.c | 12 +++++------- src/internal.h | 3 +++ src/libvirt_private.syms | 4 ++++ src/lxc/lxc_driver.c | 6 +++--- src/util/virobject.c | 16 ++++++++++++++++ src/util/virobject.h | 24 ++++++++++++++++++++++++ src/util/virthread.c | 26 ++++++++++++++++++++++++++ src/util/virthread.h | 31 +++++++++++++++++++++++++++++++ 9 files changed, 114 insertions(+), 12 deletions(-) -- 2.31.1

2 10

[PATCH] qemu: Check if unpriv_sgio is already set before trying to set it
by Michal Privoznik 05 Oct '21

05 Oct '21

In case when libvirt runs inside a restricted container it may not have enough permissions to modify unpriv_sgio. However, it may have been set beforehand by sysadmin or an orchestration tool. Therefore, let's check whether the currently set value is the one we want and if it is refrain from writing to the file. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2010306 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_conf.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 916a3d36ee..0451bc70ac 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1878,9 +1878,17 @@ qemuSetUnprivSGIO(virDomainDeviceDef *dev) * whitelist is enabled. But if requesting unfiltered access, always call * virSetDeviceUnprivSGIO, to report an error for unsupported unpriv_sgio. */ - if ((virFileExists(sysfs_path) || val == 1) && - virSetDeviceUnprivSGIO(path, NULL, val) < 0) - return -1; + if (virFileExists(sysfs_path) || val == 1) { + int curr_val; + + if (virGetDeviceUnprivSGIO(path, NULL, &curr_val) < 0) + return -1; + + if (curr_val != val && + virSetDeviceUnprivSGIO(path, NULL, val) < 0) { + return -1; + } + } return 0; } -- 2.32.0

2 1

[PATCH] qemu: capabilities: rename piix4-acpi-root-hotplug-en to more appropriate name
by Ani Sinha 05 Oct '21

05 Oct '21

The capability name piix4-acpi-root-hotplug-en is not conventional and appreared to be confusing to some. "en" suffix is also incorrect as the capability in qemu is used to both enable and disable hotplug on the pci root bus on the i440fx. Hence, rename it to piix4.acpi-root-pci-hotplug so that it is clearer, less confusing and more accurate. Signed-off-by: Ani Sinha <ani(a)anisinha.ca> --- src/qemu/qemu_capabilities.c | 2 +- tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 2 +- tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 2 +- tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 9d0c96a20c..d7b79ef7c0 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -641,7 +641,7 @@ VIR_ENUM_IMPL(virQEMUCaps, "virtio-blk.queue-size", /* QEMU_CAPS_VIRTIO_BLK_QUEUE_SIZE */ /* 410 */ - "piix4-acpi-root-hotplug-en", /* QEMU_CAPS_PIIX_ACPI_ROOT_PCI_HOTPLUG */ + "piix4.acpi-root-pci-hotplug", /* QEMU_CAPS_PIIX_ACPI_ROOT_PCI_HOTPLUG */ ); diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml index 1e5833a9f0..834fb86636 100644 --- a/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml @@ -230,7 +230,7 @@ <flag name='input-linux'/> <flag name='query-display-options'/> <flag name='virtio-blk.queue-size'/> - <flag name='piix4-acpi-root-hotplug-en'/> + <flag name='piix4.acpi-root-pci-hotplug'/> <version>5002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100243</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml index b54dd8a22e..e9d1a26400 100644 --- a/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml @@ -238,7 +238,7 @@ <flag name='query-display-options'/> <flag name='set-action'/> <flag name='virtio-blk.queue-size'/> - <flag name='piix4-acpi-root-hotplug-en'/> + <flag name='piix4.acpi-root-pci-hotplug'/> <version>6000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100242</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml index 0ad493191d..971d55e0cc 100644 --- a/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml @@ -240,7 +240,7 @@ <flag name='query-display-options'/> <flag name='set-action'/> <flag name='virtio-blk.queue-size'/> - <flag name='piix4-acpi-root-hotplug-en'/> + <flag name='piix4.acpi-root-pci-hotplug'/> <version>6001000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100243</microcodeVersion> -- 2.25.1

2 2

[PATCH 0/5] ch: Fixup object leaks and extend g_auto usage
by William Douglas 05 Oct '21

05 Oct '21

Based off of feedback from Laine to Ján's series of patches increasing g_auto usage for the ch_driver. This fixes leaks in virCHMonitorBuildKernelRelatedJson and virCHMonitorNew while tidying up and increasing the automatic cleanup for those functions and virCHMonitorBuildMemoryJson. William Douglas (5): ch_monitor: Stop leaking json value objects ch_monitor: Correctly close and ref the virCHMonitor ch: use g_auto in virCHMonitorBuildMemoryJson ch: use g_auto in virCHMonitorBuildKernelRelatedJson ch: use g_auto in virCHMonitorNew src/ch/ch_monitor.c | 59 +++++++++++++++------------------------------ src/ch/ch_monitor.h | 1 + 2 files changed, 20 insertions(+), 40 deletions(-) -- 2.33.0

3 11

[PATCH v7 0/4] Add support to enable/disable hotplug on pci-root controller
by Ani Sinha 04 Oct '21

04 Oct '21

changelog: v7: rebased the patches post libvirt release 7.8. Adjusted NEWS.rst to reflect 7.9 (unreleased) version. Changed version info for new config option in formatdomain.rst as well. Added reviewed-by tags. Also in formatdomain.rst added information on what type of hotplug (ACPI/native etc) are affected by the setting. v6: incorporated Jan's suggestions. v5: incorporated suggestions from Laine for patches #2 and #3. The qemu command line is now added in a new function and called from qemuBuildControllersByTypeCommandLine(). Output xmls are now symlinked to input xmls for unit tests. v4: split the original patchset into a pci-root controller specific patch series. also the libvirt conf is now a sub-element of the pci-root controller as was suggested by Dan Berrange. Please see discussion here: https://listman.redhat.com/archives/libvir-list/2021-September/msg00839.html v3: reorganized the patches as per Laine's suggestion. Added more details in commit messages. Added conf description in formatdomain.rst. Added changelog for next release. v2: fixed bugs and added additional missing unit tests. v1: initial implementation. Had some bugs and missed some unit tests This patchset introduces libvirt xml support to enable/disable hotplug on the pci-root controller. It adds a 'target' subelement for the pci-root controller with a 'hotplug' property. This property can be used to enable or disable hotplug for the pci-root controller. For example, in order to disable hotplug on the pci-root controller, one has to use set '<target hotplug='off'>' as shown below: <controller type='pci' model='pci-root'> <target hotplug='off'/> </controller> '<target hotplug='on'>' option would enable hotplug for pci-root controller. This is also the default value. This option is only available for pc machine types and is applicable for qemu only/kvm accelerator onlt.This feature was introduced from qemu version 5.2 with the following change in qemu repository: 3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus") The above qemu commit describes some reasons why users might to disable hotplug on PCI root buses [1]. The corresponding commandline option to qemu for x86 guests is: -global PIIX4_PM.acpi-root-pci-hotplug=<off/on> Notes: 1. The use case scenario described by Laine in https://listman.redhat.com/archives/libvir-list/2020-February/msg00110.html intentionally does not discuss i440fx and focusses solely on q35. I do realize that redhat has moved on from i440fx and currently efforts for new features are concentrated on q35 machines only. We have had some hard debates on this on the qemu mailing list before. The fact of the matter is that i440fx is not at 1-1 parity with q35. There are many users who are currenly using i440fx and are simply not ready to move to q35 without sacrificing some existing features they support today. For example https://wiki.qemu.org/images/4/4e/Q35.pdf lists some of q35 limitations. https://www.linux-kvm.org/images/0/06/2012-forum-Q35.pdf provides more information on the differences. Hence we need to solve the issue Laine has described in the above email for i440fx without adding additional bridges. Further, in Daniel Berrange's words from : https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03012.html "From the upstream POV, there's been no decision / agreement to phase out PIIX, this is purely a RHEL downstream decision & plan. If other distros / users have a different POV, and find the feature useful, we should accept the patch if it meets the normal QEMU patch requirements. " Also to be noted that I have already experimented this qemu commandline option using libvirt passthrough feature as has been documented in http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html This was only meant to be a short term solution until libvirt started supporting this natively. Supporting this option through libvirt would simplify their use case as well as add capability validations and graceful failure scenarios in case qemu did not support the option. Ani Sinha (4): qemu: capablities: detect presence of acpi-root-pci-hotplug for i440fx machines conf: introduce option to enable/disable pci hotplug on pci-root controller qemu: command: add support to enable/disable hotplug on pci-root controller NEWS: release note the new hotplug enable/disable option on pci-root controller NEWS.rst | 6 ++++ docs/formatdomain.rst | 14 ++++++--- src/qemu/qemu_capabilities.c | 4 +++ src/qemu/qemu_capabilities.h | 3 ++ src/qemu/qemu_command.c | 17 ++++++++++ src/qemu/qemu_validate.c | 9 +++++- .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + .../pc-i440fx-acpi-root-hotplug-disable.args | 31 +++++++++++++++++++ .../pc-i440fx-acpi-root-hotplug-disable.err | 1 + .../pc-i440fx-acpi-root-hotplug-disable.xml | 30 ++++++++++++++++++ .../pc-i440fx-acpi-root-hotplug-enable.xml | 30 ++++++++++++++++++ tests/qemuxml2argvtest.c | 3 ++ .../pc-i440fx-acpi-root-hotplug-disable.xml | 1 + .../pc-i440fx-acpi-root-hotplug-enable.xml | 1 + tests/qemuxml2xmltest.c | 4 +++ 17 files changed, 151 insertions(+), 6 deletions(-) create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.args create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.err create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-enable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-disable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-enable.xml -- 2.25.1

3 11

[PATCH] NEWS: cosmetic - fix indentation
by Ani Sinha 04 Oct '21

04 Oct '21

The indentation of the first item under the categoty "new features" for the future release v7.9.0 is not right. Fix it. Signed-off-by: Ani Sinha <ani(a)anisinha.ca> --- NEWS.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS.rst b/NEWS.rst index 76d2375e97..caa61f0646 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,7 +17,7 @@ v7.9.0 (unreleased) * **New features** - * Introduce virtio-mem ``<memory/>`` model + * Introduce virtio-mem ``<memory/>`` model New virtio-mem model is introduced for ``<memory/>`` device which is a paravirtualized mechanism of adding/removing memory to/from a VM. Use -- 2.25.1

2 2

[PATCH] virsh: Fix --nvram and --keep-nvram help strings
by Michal Privoznik 04 Oct '21

04 Oct '21

The --nvram and --keep-nvram options of the undefine command can be used regardless of the domain status (the only consumer so far - qemuDomainUndefineFlags() doesn't care about the domain status). Yet, their corresponding help strings say something about inactive domains while manpage says nothing. Remove the reference to domain state. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2007659 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tools/virsh-domain.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 0b78fbf728..f73d9a057e 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -3595,11 +3595,11 @@ static const vshCmdOptDef opts_undefine[] = { }, {.name = "nvram", .type = VSH_OT_BOOL, - .help = N_("remove nvram file, if inactive") + .help = N_("remove nvram file") }, {.name = "keep-nvram", .type = VSH_OT_BOOL, - .help = N_("keep nvram file, if inactive") + .help = N_("keep nvram file") }, {.name = NULL} }; -- 2.32.0

2 1

[PATCH 0/1] vmx: Fix <genid/> mapping
by Michal Privoznik 04 Oct '21

04 Oct '21

Apparently, parsing vmx.genid is not as easy as I thought. Anyway, it was brought up in a private thread that libvirt doesn't report correct UUIDs. For instance for the following input: vm.genid = "-8536691797830587195" vm.genidX = "-1723453263670062919" Libvirt would report: <genid>8987940a-0951-2cc5-e815-10634ff550b9</genid> while virt-v2v would report: <genid>09512cc5-940a-8987-b950-f54f631015e8</genid> Another example: vm.genid = "-6284418052148993891" vm.genidX = "-649955058627554545" Libvirt: <genid>a8c94313-ed9b-609d-f6fa-e5515a89530f</genid> virt-v2v: <genid>ed9b609d-4313-a8c9-0f53-895a51e5faf6</genid> To test my patch I modified tests/vmx2xmldata/esx-in-the-wild-10.vmx (because it already contains vmx.genid, but any file can be modified really), and then ran: libvirt.git/_build/tests $ VIR_TEST_DEBUG=1 VIR_TEST_RANGE=58 ./vmx2xmltest Mind you, the fix is almost direct rewrite of virt-v2v's algorithm, except it's optimized for C and not OCaml :-) You can find various attempts/versions of that on my gitlab: https://gitlab.com/MichalPrivoznik/libvirt/-/commits/vmx_genid/ I'm sending only the last one because that looks the best IMO. Michal Prívozník (1): vmx: Fix <genid/> mapping src/vmx/vmx.c | 16 ++++++++++++---- tests/vmx2xmldata/esx-in-the-wild-10.xml | 2 +- 2 files changed, 13 insertions(+), 5 deletions(-) -- 2.32.0

4 17

[PATCH] docs: describe flag VIR_STORAGE_POOL_CREATE_NORMAL to correct the HTML doc
by Erik Skultety 04 Oct '21

04 Oct '21

From: Robin Lee <cheeselee(a)fedoraproject.org> This patch makes the descriptions of virStoragePoolCreateFlags annotate to the correct flag in the generated HTML file. --- Resending a merged change from GitLab. include/libvirt/libvirt-storage.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/libvirt/libvirt-storage.h b/include/libvirt/libvirt-storage.h index b459fe3e8e..f89856b93e 100644 --- a/include/libvirt/libvirt-storage.h +++ b/include/libvirt/libvirt-storage.h @@ -70,6 +70,7 @@ typedef enum { } virStoragePoolDeleteFlags; typedef enum { + /* Create the pool but do not perform pool build */ VIR_STORAGE_POOL_CREATE_NORMAL = 0, /* Create the pool and perform pool build without any flags */ -- 2.31.1

1 0

[PATCH v5 0/4] introduce support for acpi-bridge-hotplug feature
by Ani Sinha 02 Oct '21

02 Oct '21

changelog: v5: rebased the patchset with the latest master. v4: split the original series into two - pci-root controller specific one (https://www.mail-archive.com/libvir-list@redhat.com/msg221645.html) and this one specific to pci bridges. The conf xml has been introduced as per suggestion by Berrange here: https://patchew.org/Libvirt/20210912032631.2853520-1-ani@anisinha.ca Changes has been introduced to parse and validate the xml accordingly as well as to add backend qemu commandline option. v3: reorganized the patches as per Laine's suggestion. Added more details in commit messages. Added conf description in formatdomain.rst. Added changelog for next release. v2: fixed bugs and added additional missing unit tests. v1: initial implementation. Had some bugs and missed some unit tests This change introduces a new libvirt sub-element <pci> under <features> that can be used to configure all pci related features. Currently the only sub-sub element supported by this sub-element is 'acpi-bridge-hotplug' as shown below: <features> <pci> <acpi-bridge-hotplug state='on|off'/> </pci> </features> The above option is only available for qemu driver and that too for x86 guests only. It is a global option. 'acpi-bridge-hotplug' option enables or disables ACPI hotplug support for cold-plugged pci bridges. Examples of bridges include PCI-PCI bridge (pci-bridge controller) or PCIe-PCI bridges for pc machines and pcie-root-port controller for q35 machines. Being global option, no other bridge specific option are required. For pc machine type in x86, this option is available in qemu for a long time, from version 2.1. Please see the following changes in qemu repo: 9e047b982452c6 ("piix4: add acpi pci hotplug support") 133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled") For q35 machine type, this was introduced in qemu 6.1 with the following changes in qemu repo: (a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug") (b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") The reasons for enabling ACPI based hotplug for PCIe (q35) based machines (as opposed to native hotplug) are outlined in (b). There are use cases where users would still want to use native hotplug (see notes). Therefore, this config option enables users to choose either ACPI based hotplug or native hotplug for bridges (for example for pcie root port controller in q35 machines). Notes: One concrete example of why one might still want to use native hotplug with pcie-root-port controller is the fact that we are still discovering issues with acpi hotplug on PCIE. One such issue is: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg02146.html Another reason is that users have been using native hotplug on pcie root ports up until now. They have built and tested their systems based on native hotplug. They may not want to suddenly move to acpi based hotplug just because it is now the default in qemu. Supporting the option to chose one or the other through libvirt makes things simpler for end users. Ani Sinha (4): qemu: capablities: detect presence of acpi-pci-hotplug-with-bridge-support conf: introduce support for acpi-bridge-hotplug feature qemu: command: add support for acpi-bridge-hotplug feature NEWS: add new acpi pci hotplug config option in the release note for next release NEWS.rst | 7 ++ docs/formatdomain.rst | 11 +++ docs/schemas/domaincommon.rng | 15 ++++ src/conf/domain_conf.c | 89 ++++++++++++++++++- src/conf/domain_conf.h | 9 ++ src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 14 +++ src/qemu/qemu_validate.c | 46 ++++++++++ .../caps_2.11.0.x86_64.xml | 1 + .../caps_2.12.0.x86_64.xml | 1 + .../caps_3.0.0.x86_64.xml | 1 + .../caps_3.1.0.x86_64.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 2 + .../aarch64-acpi-hotplug-bridge-disable.err | 1 + .../aarch64-acpi-hotplug-bridge-disable.xml | 33 +++++++ ...pc-i440fx-acpi-hotplug-bridge-disable.args | 31 +++++++ .../pc-i440fx-acpi-hotplug-bridge-disable.err | 1 + .../pc-i440fx-acpi-hotplug-bridge-disable.xml | 33 +++++++ .../pc-i440fx-acpi-hotplug-bridge-enable.xml | 33 +++++++ .../q35-acpi-hotplug-bridge-disable.args | 33 +++++++ .../q35-acpi-hotplug-bridge-disable.err | 1 + .../q35-acpi-hotplug-bridge-disable.xml | 47 ++++++++++ .../q35-acpi-hotplug-bridge-enable.xml | 47 ++++++++++ tests/qemuxml2argvtest.c | 16 ++++ .../pc-i440fx-acpi-hotplug-bridge-disable.xml | 1 + .../pc-i440fx-acpi-hotplug-bridge-enable.xml | 1 + .../q35-acpi-hotplug-bridge-disable.xml | 1 + .../q35-acpi-hotplug-bridge-enable.xml | 1 + tests/qemuxml2xmltest.c | 14 +++ 37 files changed, 503 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.err create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.args create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.err create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-enable.xml create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.args create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.err create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-enable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-disable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-enable.xml create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-disable.xml create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-enable.xml -- 2.25.1

1 4

[libvirt PATCH v5 0/7] Add a PCI/PCIe device VPD Capability
by Dmitrii Shcherbakov 01 Oct '21

01 Oct '21

Add support for deserializing the binary PCI/PCIe VPD format and exposing VPD resources as XML elements in a new nested capability of PCI/PCIe devices called 'vpd'. The series contains the following incremental changes: * The PCI VPD parser module, in-memory resource representation and tests; * VPD-related helpers added to the virpci module; * VPD capability support: XML serialization/deserialization from/into VPD resource data structures; * Documentation. The VPD format is specified in "I.3. VPD Definitions" in PCI specs (2.2+) and "6.28.1 VPD Format" PCIe 4.0. As section 6.28 in PCIe 4.0 notes, the PCI Local Bus and PCIe VPD formats are binary compatible and PCIe 4.0 merely started incorporating what was already present in PCI specs. Linux kernel exposes a binary blob in the VPD format via sysfs since v2.6.26 (commit 94e6108803469a37ee1e3c92dafdd1d59298602f) which requires a parser to interpret. There are usage scenarios where information such as the board serial number needs to be retrieved from PCI(e) VPD. Projects like Nova can utilize this information for cases which involve virtual interface plugging on SmartNIC DPUs but there may be other scenarios and types of information useful to retrieve from VPD. The fact that the format is binary requires proper parsing instead of substring searching hence the full parser is proposed. Likewise, checksum validation requires proper parsing as well. A usage example is present here: https://review.opendev.org/c/openstack/nova/+/808199 The patch follows a prior discussion on the mailing list which has additional context about the use-case but a narrower proposal: https://listman.redhat.com/archives/libvir-list/2021-May/msg00873.html https://www.mail-archive.com/libvir-list@redhat.com/msg218165.html The new functionality is mostly contained in virpcivpd with a couple of new functions added to virpci. Additionally, the necessary XML serialization/deserialization and glue code is added to expose the VPD capability to external clients as XML. A new capability flag is added along with a new capability in order to allow for filtering of PCI devices with the VPD capability using virsh: virsh nodedev-list --cap vpd sudo virsh nodedev-dumpxml --device pci_dddd_bb_ss_f In this example having the root uid is required in order to access the vpd sysfs entry, therefore, the nodedev XML output will only contain the VPD capability if virsh is run as root. The capability is treated as dynamic due to the presence of read-write sections in the VPD format per PCI/PCIe specs (the idea being that read-write resource fields may potentially be altered by the DPU OS over time independently from the host OS). Unit tests cover the parser functionality (including many possible invalid cases), in-memory representation as well as XML serialization and deserialization. Manual functional testing was performed with 2 DPUs and several other NIC models which expose PCI(e) VPD. Testing have also been performed for devices that do not have VPD or those that expose a VPD capability but exhibit invalid behavior (I/O errors while reading a sysfs entry). Per the existing guidelines, the implementation relies heavily on glib for various purposes. https://libvirt.org/glib-adoption.html * v5 fixes a couple of minor typos and adds NEWS entries. * The v4 of the patch includes a number of fixes compared to v3: * Fixed the patch to correctly build against older glib (2.56.0); * Notably, glib commit 86c073dba9d82ef3f1bc3d3116b058b9b5c3b1eb (in 2.59.0) fixes g_autolist support for derivable Glib types. To make things work in 2.56.0 a workaround is conditionally applied; * virCreateAnonymousFile now uses a temporary file which is unlinked after creation instead of memfd because OpenSUSE 15.2 does not have support memfd; * Keyword resources now use GTree instead of GHashTable as the underlying data structure: * This allows for stable ordering which is important for XML2XML tests as they were failing with when GLib versions were different, resulting in a different ordering of elements; * The keyword resource iteration function was complex and got replaced by a simpler g_tree_foreach-based approach; * Added more testing: functions added to virpci are now assessed by creating a mocked vpd file under a mocked sysfs structure while the parser is still tested in virpcivpdtest file; * Refactoring: * Applied changes based on the indent tool operation with some post-processing; * Renamed functions which had the Glib naming style to use camel case where possible. Auto-generated declarations are an exception: gobject/gtype.h defines type_name##_init, type_name##_class_init, module_obj_name##_get_type functions which were left unchanged; * camelCase is now used for local variables and function parameters; * Replaced //-style comments with multi-line ones; * Split out one patch into 4 based on distinct features: * PCI VPD parser functionality and the respective in-memory types; * VPD helpers in virpci; * XML serialization/deserialization and VPD capability support; * Documentation. Build & test results for targets in ci/manifest.yaml: ci/helper test --meson-args='-Dexpensive_tests=enabled' <target> https://gist.github.com/dshcherb/225b5da9478275f08c220487814ffd1c Dmitrii Shcherbakov (7): Add a PCI/PCIe device VPD Parser News: Add a PCI VPD parser Add PCI VPD-related helper functions to virpci News: Add PCI VPD-related helper functions to virpci Add PCI VPD Capability Support News: Add PCI VPD capability support Add PCI VPD Capability Documentation NEWS.rst | 22 + build-aux/syntax-check.mk | 4 +- docs/drvnodedev.html.in | 46 ++ docs/formatnode.html.in | 24 +- docs/schemas/nodedev.rng | 40 + include/libvirt/libvirt-nodedev.h | 1 + po/POTFILES.in | 1 + src/conf/node_device_conf.c | 271 +++++++ src/conf/node_device_conf.h | 6 +- src/conf/virnodedeviceobj.c | 7 +- src/libvirt_private.syms | 17 + src/node_device/node_device_driver.c | 2 + src/node_device/node_device_udev.c | 2 + src/util/meson.build | 1 + src/util/virpci.c | 62 ++ src/util/virpci.h | 3 + src/util/virpcivpd.c | 755 ++++++++++++++++++ src/util/virpcivpd.h | 117 +++ src/util/virpcivpdpriv.h | 45 ++ tests/meson.build | 1 + .../pci_0000_42_00_0_vpd.xml | 33 + .../pci_0000_42_00_0_vpd.xml | 1 + tests/nodedevxml2xmltest.c | 1 + tests/testutils.c | 40 + tests/testutils.h | 4 + tests/virpcimock.c | 30 + tests/virpcitest.c | 64 ++ tests/virpcivpdtest.c | 705 ++++++++++++++++ tools/virsh-nodedev.c | 3 + 29 files changed, 2303 insertions(+), 5 deletions(-) create mode 100644 src/util/virpcivpd.c create mode 100644 src/util/virpcivpd.h create mode 100644 src/util/virpcivpdpriv.h create mode 100644 tests/nodedevschemadata/pci_0000_42_00_0_vpd.xml create mode 120000 tests/nodedevxml2xmlout/pci_0000_42_00_0_vpd.xml create mode 100644 tests/virpcivpdtest.c -- 2.30.2

3 23

Release of libvirt-7.8.0
by Jiri Denemark 01 Oct '21

01 Oct '21

The 7.8.0 release of both libvirt and libvirt-python is tagged and signed tarballs and source RPMs are available at https://libvirt.org/sources/ https://libvirt.org/sources/python/ Thanks everybody who helped with this release by sending patches, reviewing, testing, or providing feedback. Your work is greatly appreciated. * New features * nodedev: Add ability to automatically start mediated devices The autostart status of a persistent mediated devices can be managed with the new APIs ``virNodeDeviceSetAutostart()`` and ``virNodeDeviceGetAutostart()``. The corresponding virsh command is ``nodedev-autostart``. In addition, two new APIs were added to get additional information about node devices: ``virNodeDeviceIsPersistent()`` checks whether the device is persistently defined, and ``virNodeDeviceIsActive()`` checks whether the node device is currently active. This information can also be retrieved with the new virsh command ``nodedev-info``. Enjoy. Jirka

1 0

[PATCH] conf: fix block type CDROM cannot support startupPolicy
by Jie Wang 01 Oct '21

01 Oct '21

block type CDROM also support startupPolicy in the past, so let us fix it. Signed-off-by: Jie Wang <wangjie88(a)huawei.com> --- src/conf/domain_conf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index f7025bffe4..dd374e8ab3 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -30853,9 +30853,10 @@ virDomainDiskTranslateSourcePool(virDomainDiskDef *def) } if (def->startupPolicy != 0 && - virStorageSourceGetActualType(def->src) != VIR_STORAGE_TYPE_FILE) { + (virStorageSourceGetActualType(def->src) != VIR_STORAGE_TYPE_FILE && + virStorageSourceGetActualType(def->src) != VIR_STORAGE_TYPE_BLOCK)) { virReportError(VIR_ERR_XML_ERROR, "%s", - _("'startupPolicy' is only valid for 'file' type volume")); + _("'startupPolicy' is only valid for 'file' or 'block' type volume")); return -1; } -- 2.24.0.windows.2

3 2

Re: [PATCH] failover: allow to pause the VM during the migration
by Laine Stump 01 Oct '21

01 Oct '21

On 9/30/21 1:09 PM, Laurent Vivier wrote: > If we want to save a snapshot of a VM to a file, we used to follow the > following steps: > > 1- stop the VM: > (qemu) stop > > 2- migrate the VM to a file: > (qemu) migrate "exec:cat > snapshot" > > 3- resume the VM: > (qemu) cont > > After that we can restore the snapshot with: > qemu-system-x86_64 ... -incoming "exec:cat snapshot" > (qemu) cont This is the basics of what libvirt does for a snapshot, and steps 1+2 are what it does for a "managedsave" (where it saves the snapshot to disk and then terminates the qemu process, for later re-animation). In those cases, it seems like this new parameter could work for us - instead of explicitly pausing the guest prior to migrating it to disk, we would set this new parameter to on, then directly migrate-to-disk (relying on qemu to do the pause). Care will need to be taken to assure that error recovery behaves the same though. There are a couple of cases when libvirt apparently *doesn't* pause the guest during the migrate-to-disk, both having to do with saving a coredump of the guest. Since I really have no idea of how common/important that is (or even if my assessment of the code is correct), I'm Cc'ing this patch to libvir-list to make sure it catches the attention of someone who knows the answers and implications. > But when failover is configured, it doesn't work anymore. > > As the failover needs to ask the guest OS to unplug the card > the machine cannot be paused. > > This patch introduces a new migration parameter, "pause-vm", that > asks the migration to pause the VM during the migration startup > phase after the the card is unplugged. > > Once the migration is done, we only need to resume the VM with > "cont" and the card is plugged back: > > 1- set the parameter: > (qemu) migrate_set_parameter pause-vm on > > 2- migrate the VM to a file: > (qemu) migrate "exec:cat > snapshot" > > The primary failover card (VFIO) is unplugged and the VM is paused. > > 3- resume the VM: > (qemu) cont > > The VM restarts and the primary failover card is plugged back > > The VM state sent in the migration stream is "paused", it means > when the snapshot is loaded or if the stream is sent to a destination > QEMU, the VM needs to be resumed manually. > > Signed-off-by: Laurent Vivier <lvivier(a)redhat.com> > --- > qapi/migration.json | 20 +++++++++++++++--- > include/hw/virtio/virtio-net.h | 1 + > hw/net/virtio-net.c | 33 ++++++++++++++++++++++++++++++ > migration/migration.c | 37 +++++++++++++++++++++++++++++++++- > monitor/hmp-cmds.c | 8 ++++++++ > 5 files changed, 95 insertions(+), 4 deletions(-) > > diff --git a/qapi/migration.json b/qapi/migration.json > index 88f07baedd06..86284d96ad2a 100644 > --- a/qapi/migration.json > +++ b/qapi/migration.json > @@ -743,6 +743,10 @@ > # block device name if there is one, and to their node name > # otherwise. (Since 5.2) > # > +# @pause-vm: Pause the virtual machine before doing the migration. > +# This allows QEMU to unplug a card before doing the > +# migration as it depends on the guest kernel. (since 6.2) > +# > # Since: 2.4 > ## > { 'enum': 'MigrationParameter', > @@ -758,7 +762,7 @@ > 'xbzrle-cache-size', 'max-postcopy-bandwidth', > 'max-cpu-throttle', 'multifd-compression', > 'multifd-zlib-level' ,'multifd-zstd-level', > - 'block-bitmap-mapping' ] } > + 'block-bitmap-mapping', 'pause-vm' ] } > > ## > # @MigrateSetParameters: > @@ -903,6 +907,10 @@ > # block device name if there is one, and to their node name > # otherwise. (Since 5.2) > # > +# @pause-vm: Pause the virtual machine before doing the migration. > +# This allows QEMU to unplug a card before doing the > +# migration as it depends on the guest kernel. (since 6.2) > +# > # Since: 2.4 > ## > # TODO either fuse back into MigrationParameters, or make > @@ -934,7 +942,8 @@ > '*multifd-compression': 'MultiFDCompression', > '*multifd-zlib-level': 'uint8', > '*multifd-zstd-level': 'uint8', > - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } } > + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ], > + '*pause-vm': 'bool' } } > > ## > # @migrate-set-parameters: > @@ -1099,6 +1108,10 @@ > # block device name if there is one, and to their node name > # otherwise. (Since 5.2) > # > +# @pause-vm: Pause the virtual machine before doing the migration. > +# This allows QEMU to unplug a card before doing the > +# migration as it depends on the guest kernel. (since 6.2) > +# > # Since: 2.4 > ## > { 'struct': 'MigrationParameters', > @@ -1128,7 +1141,8 @@ > '*multifd-compression': 'MultiFDCompression', > '*multifd-zlib-level': 'uint8', > '*multifd-zstd-level': 'uint8', > - '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } } > + '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ], > + '*pause-vm': 'bool' } } > > ## > # @query-migrate-parameters: > diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h > index 824a69c23f06..a6c186e28b45 100644 > --- a/include/hw/virtio/virtio-net.h > +++ b/include/hw/virtio/virtio-net.h > @@ -210,6 +210,7 @@ struct VirtIONet { > bool failover; > DeviceListener primary_listener; > Notifier migration_state; > + VMChangeStateEntry *vm_state; > VirtioNetRssData rss_data; > struct NetRxPkt *rx_pkt; > struct EBPFRSSContext ebpf_rss; > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c > index f205331dcf8c..c83364eac47b 100644 > --- a/hw/net/virtio-net.c > +++ b/hw/net/virtio-net.c > @@ -39,6 +39,7 @@ > #include "migration/misc.h" > #include "standard-headers/linux/ethtool.h" > #include "sysemu/sysemu.h" > +#include "sysemu/runstate.h" > #include "trace.h" > #include "monitor/qdev.h" > #include "hw/pci/pci.h" > @@ -3303,6 +3304,35 @@ static void virtio_net_migration_state_notifier(Notifier *notifier, void *data) > virtio_net_handle_migration_primary(n, s); > } > > +static void virtio_net_failover_restart_cb(void *opaque, bool running, > + RunState state) > +{ > + DeviceState *dev; > + VirtIONet *n = opaque; > + Error *err = NULL; > + PCIDevice *pdev; > + > + if (!running) { > + return; > + } > + > + dev = failover_find_primary_device(n); > + if (!dev) { > + return; > + } > + > + pdev = PCI_DEVICE(dev); > + if (!pdev->partially_hotplugged) { > + return; > + } > + > + if (!failover_replug_primary(n, dev, &err)) { > + if (err) { > + error_report_err(err); > + } > + } > +} > + > static bool failover_hide_primary_device(DeviceListener *listener, > QemuOpts *device_opts) > { > @@ -3360,6 +3390,8 @@ static void virtio_net_device_realize(DeviceState *dev, Error **errp) > device_listener_register(&n->primary_listener); > n->migration_state.notify = virtio_net_migration_state_notifier; > add_migration_state_change_notifier(&n->migration_state); > + n->vm_state = qemu_add_vm_change_state_handler( > + virtio_net_failover_restart_cb, n); > n->host_features |= (1ULL << VIRTIO_NET_F_STANDBY); > } > > @@ -3508,6 +3540,7 @@ static void virtio_net_device_unrealize(DeviceState *dev) > if (n->failover) { > device_listener_unregister(&n->primary_listener); > remove_migration_state_change_notifier(&n->migration_state); > + qemu_del_vm_change_state_handler(n->vm_state); > } > > max_queues = n->multiqueue ? n->max_queues : 1; > diff --git a/migration/migration.c b/migration/migration.c > index bb909781b7f5..9c96986d4abf 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -901,6 +901,9 @@ MigrationParameters *qmp_query_migrate_parameters(Error **errp) > s->parameters.block_bitmap_mapping); > } > > + params->has_pause_vm = true; > + params->pause_vm = s->parameters.pause_vm; > + > return params; > } > > @@ -1549,6 +1552,11 @@ static void migrate_params_test_apply(MigrateSetParameters *params, > dest->has_block_bitmap_mapping = true; > dest->block_bitmap_mapping = params->block_bitmap_mapping; > } > + > + if (params->has_pause_vm) { > + dest->has_pause_vm = true; > + dest->pause_vm = params->pause_vm; > + } > } > > static void migrate_params_apply(MigrateSetParameters *params, Error **errp) > @@ -1671,6 +1679,10 @@ static void migrate_params_apply(MigrateSetParameters *params, Error **errp) > QAPI_CLONE(BitmapMigrationNodeAliasList, > params->block_bitmap_mapping); > } > + > + if (params->has_pause_vm) { > + s->parameters.pause_vm = params->pause_vm; > + } > } > > void qmp_migrate_set_parameters(MigrateSetParameters *params, Error **errp) > @@ -1718,6 +1730,12 @@ void qmp_migrate_start_postcopy(Error **errp) > " started"); > return; > } > + > + if (s->parameters.pause_vm) { > + error_setg(errp, "Postcopy cannot be started if pause-vm is on"); > + return; > + } > + > /* > * we don't error if migration has finished since that would be racy > * with issuing this command. > @@ -3734,13 +3752,27 @@ static void qemu_savevm_wait_unplug(MigrationState *s, int old_state, > "failure"); > } > } > - > migrate_set_state(&s->state, MIGRATION_STATUS_WAIT_UNPLUG, new_state); > } else { > migrate_set_state(&s->state, old_state, new_state); > } > } > > +/* stop the VM before starting the migration but after device unplug */ > +static void pause_vm_after_unplug(MigrationState *s) > +{ > + if (s->parameters.pause_vm) { > + qemu_mutex_lock_iothread(); > + qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER, NULL); > + s->vm_was_running = runstate_is_running(); > + if (vm_stop_force_state(RUN_STATE_PAUSED)) { > + migrate_set_state(&s->state, MIGRATION_STATUS_ACTIVE, > + MIGRATION_STATUS_FAILED); > + } > + qemu_mutex_unlock_iothread(); > + } > +} > + > /* > * Master migration thread on the source VM. > * It drives the migration and pumps the data down the outgoing channel. > @@ -3790,6 +3822,8 @@ static void *migration_thread(void *opaque) > qemu_savevm_wait_unplug(s, MIGRATION_STATUS_SETUP, > MIGRATION_STATUS_ACTIVE); > > + pause_vm_after_unplug(s); > + > s->setup_time = qemu_clock_get_ms(QEMU_CLOCK_HOST) - setup_start; > > trace_migration_thread_setup_complete(); > @@ -4265,6 +4299,7 @@ static void migration_instance_init(Object *obj) > params->has_announce_max = true; > params->has_announce_rounds = true; > params->has_announce_step = true; > + params->has_pause_vm = true; > > qemu_sem_init(&ms->postcopy_pause_sem, 0); > qemu_sem_init(&ms->postcopy_pause_rp_sem, 0); > diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c > index b5e71d9e6f52..71bc8c15335b 100644 > --- a/monitor/hmp-cmds.c > +++ b/monitor/hmp-cmds.c > @@ -513,6 +513,10 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict *qdict) > } > } > } > + > + monitor_printf(mon, "%s: %s\n", > + MigrationParameter_str(MIGRATION_PARAMETER_PAUSE_VM), > + params->pause_vm ? "on" : "off"); > } > > qapi_free_MigrationParameters(params); > @@ -1399,6 +1403,10 @@ void hmp_migrate_set_parameter(Monitor *mon, const QDict *qdict) > error_setg(&err, "The block-bitmap-mapping parameter can only be set " > "through QMP"); > break; > + case MIGRATION_PARAMETER_PAUSE_VM: > + p->has_pause_vm = true; > + visit_type_bool(v, param, &p->pause_vm, &err); > + break; > default: > assert(0); > } >

4 3

translating CD-ROM device paths from i440fx to Q35 in virt-v2v (was: test-v2v-cdrom: update the CD-ROM's bus to SATA in the converted domain)
by Laszlo Ersek 30 Sep '21

30 Sep '21

(+libvirt-devel) On 09/29/21 21:22, Richard W.M. Jones wrote: > We currently partially install the virtio block drivers in the Windows > guest (just enough to get the guest to boot on the target), and > Windows itself re-installs the virtio block driver and other drivers > it needs, and that's enough to get it to see C: > > As for other hard disk partitions, Windows does indeed contain a > mapping to other drives in the Registry but IIRC it's not sensitive to > the device driver (unlike Linux /dev/vdX vs /dev/sdX). If you're > interested in that, see libguestfs.git/daemon/inspect_fs_windows.ml: > get_drive_mappings. We never bothered with attempting to handle > conversion of floppy drives or CD-ROMs for Windows. OK. So AIUI, that means no work is needed here for Windows. > On Linux we do better: We iterate over all the configuration files in > /etc and change device paths. The significance of this bug is we need > to change (eg) /dev/hdc to /dev/<something>. The difficulty is > working out where the device will appear on the target and not having > it conflict with any hard disk, something we partly control (see > virt-v2v.git/convert/target_bus_assignment.ml*) AIUI the conflict avoidance logic ("no overlapping disks") is already in place. The question is how to translate device paths in /etc/fstab and similar. Please correct me if I'm wrong: at the moment, I believe virt-v2v parses and manipulates the following elements and attributes in the domain XML: <target dev='hda' bus='ide'/> <target dev='hdb' bus='ide'/> <target dev='hdc' bus='ide'/> <target dev='hdd' bus='ide'/> ^^^ ^^^ My understanding is however that the target/@dev attribute is mostly irrelevant: https://libvirt.org/formatdomain.html#hard-drives-floppy-disks-cdroms The dev attribute indicates the "logical" device name. The actual device name specified is not guaranteed to map to the device name in the guest OS. Treat it as a device ordering hint. [...] What actually matters is the target/@bus attribute, in combination with the sibling element <address>. Such as: <target dev='hda' bus='ide'/> ^^^ <address type='drive' controller='0' bus='0' target='0' unit='0'/> ^ ^ ^ <target dev='hdb' bus='ide'/> ^^^ <address type='drive' controller='0' bus='0' target='0' unit='1'/> ^ ^ ^ <target dev='hdc' bus='ide'/> ^^^ <address type='drive' controller='0' bus='1' target='0' unit='0'/> ^ ^ ^ <target dev='hdd' bus='ide'/> ^^^ <address type='drive' controller='0' bus='1' target='0' unit='1'/> ^ ^ ^ So, target/@dev should be mostly ignored; what matters is the following tuple: (target/@bus, address/@controller, address/@bus, address/@unit) Extracting just the tuples: (ide, 0, 0, 0) (ide, 0, 0, 1) (ide, 0, 1, 0) (ide, 0, 1, 1) The first two components of each tuple -- i.e., (ide, 0) -- refer to the following IDE controller: <controller type='ide' index='0'> ^^^^^^^^^^ ^^^^^^^^^ <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> and then the rest of the components, such as (0, 0), (0, 1), (1, 0), (1, 1), identify the disk on that IDE controller. (Side comment: the PCI location of the (first) IDE controller is fixed in QEMU; if one tries to change it, libvirt complains: "Primary IDE controller must have PCI address 0:0:1.1".) (Side comment: on the QEMU command line, this maps to -device ide-cd,bus=ide.0,unit=0,... \ -device ide-cd,bus=ide.0,unit=1,... \ -device ide-cd,bus=ide.1,unit=0,... \ -device ide-cd,bus=ide.1,unit=1,... \ ) Inside the guest, /dev/hd* nodes don't even exist, so it's unlikely that /etc/fstab would refer to them. /etc/fstab can however refer to symlinks under "/dev/disk/by-id" (for example): lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00001 -> ../../sr0 lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00002 -> ../../sr1 lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00003 -> ../../sr2 lrwxrwxrwx. 1 root root 9 Sep 30 11:54 ata-QEMU_DVD-ROM_QM00004 -> ../../sr3 Furthermore, we have pseudo-files (directories) such as: /sys/devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:0/0:0:0:0/block/sr0 /sys/devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:1/0:0:1:0/block/sr1 /sys/devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:0/1:0:0:0/block/sr2 /sys/devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:1/1:0:1:0/block/sr3 ^ ^ So in order to map a device path from the original guest's "/etc/fstab", such as "/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003", to the original domain XML's <disk> element, we have to do the following in the "source" appliance: NODE=$(realpath /dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003) # -> /dev/sr2 NODE=${NODE#/dev/} # -> sr2 DEVPATH=$(ls -d /sys/devices/pci0000:00/0000:00:01.1/ata?/host?/target?:0:?/?:0:?:0/block/$NODE) # -> /sys/devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:0/1:0:0:0/block/sr2 And then map the "1:0:0:0" pathname component from $DEVPATH to: <target dev='hdc' bus='ide'/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> ^^^^^^^ ^^^^^^^^ [1]:0:0:0 1:0:[0]:0 in the original domain XML. This tells us under what device node the original guest sees the host-side file (<source> element). After conversion, on the Q35 board, the inverse mapping is needed. We start from the domain XML, <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='4'/> <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='5'/> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> (Side comment: the PCI B/D/F of the SATA controller is also fixed in QEMU; otherwise libvirt complains: "Primary SATA controller must have PCI address 0:0:1f.2".) (Side comment: the QEMU command line is -device ide-cd,bus=ide.0,... \ -device ide-cd,bus=ide.1,... \ -device ide-cd,bus=ide.2,... \ -device ide-cd,bus=ide.3,... \ -device ide-cd,bus=ide.4,... \ -device ide-cd,bus=ide.5,... \ ) In the guest we have: /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0 /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr1 /sys/devices/pci0000:00/0000:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sr2 /sys/devices/pci0000:00/0000:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sr3 /sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sr4 /sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sr5 So, assuming we mapped the original (i440fx) "/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003" guest device path to some <source> element (= host-side file) in the original domain XML, and assuming virt-v2v assigned the same <source> element to the following element on the Q35 board: <target dev='sd*' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='4'/> ^^^^^^^^ we find the device node in the destination appliance as follows: NODE=$(basename /sys/devices/pci0000:00/0000:00:1f.2/ata?/host?/target?:0:0/4:0:0:0/block/*) ^ unit='4' # -> sr4 and then replace "/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003" with "/dev/sr4" in "/etc/fstab". All this requires virt-v2v to parse complete <address> elements from the original domain XML, and to generate complete <address> elements in the destination domain XML. Is that feasible? The @wwn and @serial attributes don't look safe to me, because the guest could refer to them even when the original domain XML does not spell them out (eg. "QM00003" is such a @serial). So neither can we trust that a @serial is present in the original XML, nor can we just go ahead and generate a @serial if it is absent. (The generation step could immediately break references such as "QM00003" in the guest.) /dev/disk/by-label and /dev/disk/by-uuid are based on media contents, and multiple CD-ROMs may (read-only) map the same host-side file, so those are not good for mapping either, I think. Also does not cover CD-ROM devices that are empty (have no medium) at the time of conversion, but "/etc/fstab" still refers to them (potentially with "noauto"). So I think the only reliable ID is the hardware device path. ... Now if *that* needs to work when the original guest comes from a different management application than libvirt, then I have no idea. The original address (PCI B/D/F of the IDE controller, and IDE bus and unit of the drive) need to be known somehow; otherwise we cannot associate the guest-side "/dev/..." reference with the host-side file underlying that CD-ROM. Thanks, Laszlo

3 3

[PATCH v3 0/5] Add support for two i386 pm options which control acpi hotplug
by Ani Sinha 30 Sep '21

30 Sep '21

Hi all: This patchset introduces libvirt xml support for the following two pm conf options: <pm> <acpi-hotplug-bridge enabled='no'/> <acpi-root-hotplug enabled='yes'/> </pm> The above two options are only available for qemu driver and that too for x86 guests only. Both of them are global options. ``acpi-hotplug-bridge`` option enables or disables ACPI hotplug support for cold plugged bridges. Examples of cold plugged bridges include PCI-PCI bridge (pci-bridge controller) for pc machines and pcie-root-port controller for q35 machines. The corresponding commandline options to qemu for x86 guests are: (pc machines): -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=<off/on> (q35 machines): -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=<off/on> Being global options, no other bridge specific options for pci-bridge controller or pcie-root-port controllers are required. For pc machine type in x86, this option is available in qemu for a long time, from version 2.1. Please see the changes in qemu.git: 9e047b982452c6 ("piix4: add acpi pci hotplug support") 133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled") For q35 machine type, this was introduced in qemu 6.1 with the following changes in qemu.git: (a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug") (b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") The reasons for enabling ACPI based hotplug for PCIe (q35) based machines (as opposed to native hotplug) for bridges are outlined in (b). It is possible that some users might still want to use native hotplug on PCIe [1]. Therefore, this conf option enables users to choose either ACPI based hotplug or native hotplug for cold plugged bridges (for example for pcie root port controller in q35 machines). ``acpi-root-hotplug`` option enables or disables ACPI based hotplug for PCI root bus (pci-root controller). This option is only available for pc machine type. The corresponding commandline option to qemu for x86 guests is: -global PIIX4_PM.acpi-root-pci-hotplug=<off/on> This additional option enables users to disable hotplug for all devices in the system without adding an additional PCI-PCI bridge, putting the devices behind the bridge and using the existing ``acpi-hotplug-bridge`` option to disable hotplug on that bridge. This feature was introduced from qemu version 5.2 with the following change in qemu.git: 3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus") The above qemu commit describes some compelling reasons why users might to disable hotplug on PCI root buses [2]. A brief summary of the patches: >[PATCH v3 1/5] qemu: capablities: detect presence of >[PATCH v3 2/5] qemu: capablities: detect presence of Patches 1 and 2 implement support for qemu capability checks for the above config options. >[PATCH v3 3/5] conf: introduce acpi-hotplug-bridge and Patch 3 actually adds the config option to the schema and adds related unit tests. >[PATCH v3 4/5] qemu: command: add support for qemu options that Patch 4 adds the backend qemu commandline support for the options. It also adds relevant unit tests for the same. >[PATCH v3 5/5] NEWS: add new acpi pci hotplug options in the release Patch 5 adds the release notes for the next libvirt release. Changelog: v1: initial implementation. Had some bugs and missed some unit tests. v2: fixed bugs and added additional missing unit tests. v3: reorganized the patches as per Laine's suggestion. Added more details in commit messages. Added conf description in formatdomain.rst. Added changelog for next release. Notes: [1] One concrete example of why one might still want to use native hotplug with pcie-root-port controller is the fact that we are still discovering issues with acpi hotplug on PCIE. One such issue is: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg02146.html Another reason is that users have been using native hotplug on pcie root ports up until now. They have built and tested their systems based on native hotplug. They may not want to suddenly move to acpi based hotplug just because it is now the default in qemu. Supporting the option to chose one or the other through libvirt makes things simpler for end users. [2] The use case scenario described by Laine in https://listman.redhat.com/archives/libvir-list/2020-February/msg00110.html intentionally does not discuss i440fx and focusses solely on q35. I do realize that redhat has moved on from i440fx and currently efforts for new features are concentrated on q35 machines only. We have had some hard debates on this on the qemu mailing list before. The fact of the matter is that i440fx is not at 1-1 parity with q35. There are many users who are currenly using i440fx and are simply not ready to move to q35 without sacrificing some existing features they support today. For example https://wiki.qemu.org/images/4/4e/Q35.pdf lists some of q35 limitations. https://www.linux-kvm.org/images/0/06/2012-forum-Q35.pdf provides more information on the differences. Hence we need to solve the issue Laine has described in the above email for i440fx without adding additional bridges. Further, in Daniel Berrange's words from : https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03012.html "From the upstream POV, there's been no decision / agreement to phase out PIIX, this is purely a RHEL downstream decision & plan. If other distros / users have a different POV, and find the feature useful, we should accept the patch if it meets the normal QEMU patch requirements. " Also to be noted that I have already experimented this qemu commandline option using libvirt passthrough feature as has been documented in http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html This was only meant to be a short term solution until libvirt started supporting this natively. Supporting this option through libvirt would simplify their use case as well as add capability validations and graceful failure scenarios in case qemu did not support the option. [3] Finally, I implemented support for ``acpi-root-hotplug`` option in Qemu. Since adding the support for this option, I have not run away :-) I am still around, fixing other issues in the same subsystem in qemu and also now I have added myself as a reviewer of patches in this area. I will also be trying to support/maintain this new xml conf option in libvirt to the extent I can in future with the help of other experienced maintainers. Obviously this is all freelance work at this moment and is highly dependent on available free time.

4 42

[PATCH] qemuDomainChangeDiskLive: Modify 'startupPolicy' before changing source
by Peter Krempa 30 Sep '21

30 Sep '21

We don't support all startup policies with all source types so to correctly allow switching from a 'file' based cdrom with 'optional' startup policy to a 'block' based one which doesn't support optional we must update the startup policy field first. Obviously we need to have fallback if the update fails. Reported-by: Vojtech Juranek <vjuranek(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_driver.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index bd41ddbc3c..dfc27572c4 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -7038,6 +7038,7 @@ qemuDomainChangeDiskLive(virDomainObj *vm, { virDomainDiskDef *disk = dev->data.disk; virDomainDiskDef *orig_disk = NULL; + virDomainStartupPolicy origStartupPolicy; virDomainDeviceDef oldDev = { .type = dev->type }; if (!(orig_disk = virDomainDiskByTarget(vm->def, disk->dst))) { @@ -7047,6 +7048,7 @@ qemuDomainChangeDiskLive(virDomainObj *vm, } oldDev.data.disk = orig_disk; + origStartupPolicy = orig_disk->startupPolicy; if (virDomainDefCompatibleDevice(vm->def, dev, &oldDev, VIR_DOMAIN_DEVICE_ACTION_UPDATE, true) < 0) @@ -7065,13 +7067,20 @@ qemuDomainChangeDiskLive(virDomainObj *vm, return -1; } + /* update startup policy first before updating disk image */ + orig_disk->startupPolicy = dev->data.disk->startupPolicy; + if (qemuDomainChangeEjectableMedia(driver, vm, orig_disk, - dev->data.disk->src, force) < 0) + dev->data.disk->src, force) < 0) { + /* revert startup policy before failing */ + orig_disk->startupPolicy = origStartupPolicy; return -1; + } dev->data.disk->src = NULL; } + /* in case when we aren't updating disk source we update startup policy here */ orig_disk->startupPolicy = dev->data.disk->startupPolicy; orig_disk->snapshot = dev->data.disk->snapshot; -- 2.31.1

5 8