October 2021 - Devel - libvirt List Archives

[PATCH v2] qemu: tpm: Run swtpm_setup --create-config-files in session mode
by Stefan Berger 08 Oct '21

08 Oct '21

Using swtpm v0.7.0 we can run swtpm_setup to create default config files for swtpm_setup and swtpm-localca in session mode. Now a user can start a VM with an attached TPM without having to run this program on the command line before. This program needs to run once. This patch addresses the issue raised in https://bugzilla.redhat.com/show_bug.cgi?id=2010649 Signed-off-by: Stefan Berger <stefanb(a)linux.ibm.com> v2: - fixed return code if swtpm_setup doesn't support the option --- src/qemu/qemu_tpm.c | 43 +++++++++++++++++++++++++++++++++++++++++++ src/util/virtpm.c | 1 + src/util/virtpm.h | 1 + 3 files changed, 45 insertions(+) diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c index 100481503c..bf6c8e5ad5 100644 --- a/src/qemu/qemu_tpm.c +++ b/src/qemu/qemu_tpm.c @@ -385,6 +385,46 @@ qemuTPMSetupEncryption(const unsigned char *secretuuid, return virCommandSetSendBuffer(cmd, g_steal_pointer(&secret), secret_len); } + +/* + * qemuTPMCreateConfigFiles: run swtpm_setup --create-config-files skip-if-exist + * + * @logfile: The file to write the log into; it must be writable + * for the user given by userid or 'tss' + */ +static int +qemuTPMCreateConfigFiles(const char *logfile) +{ + g_autofree char *swtpm_setup = virTPMGetSwtpmSetup(); + g_autoptr(virCommand) cmd = NULL; + int exitstatus; + + if (!swtpm_setup) + return -1; + + if (!virTPMSwtpmSetupCapsGet( + VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES)) + return 0; + + cmd = virCommandNew(swtpm_setup); + if (!cmd) + return -1; + + virCommandAddArgList(cmd, "--create-config-files", "skip-if-exist", NULL); + virCommandClearCaps(cmd); + + if (virCommandRun(cmd, &exitstatus) < 0 || exitstatus != 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Could not run '%s' to create config files. exitstatus: %d; " + "Check error log '%s' for details."), + swtpm_setup, exitstatus, logfile); + return -1; + } + + return 0; +} + + /* * qemuTPMEmulatorRunSetup * @@ -432,6 +472,9 @@ qemuTPMEmulatorRunSetup(const char *storagepath, "this requires privileged mode for a " "TPM 1.2\n"), 0600); + if (!privileged && qemuTPMCreateConfigFiles(logfile)) + return -1; + cmd = virCommandNew(swtpm_setup); if (!cmd) return -1; diff --git a/src/util/virtpm.c b/src/util/virtpm.c index 1a567139b4..0f50de866c 100644 --- a/src/util/virtpm.c +++ b/src/util/virtpm.c @@ -45,6 +45,7 @@ VIR_ENUM_IMPL(virTPMSwtpmFeature, VIR_ENUM_IMPL(virTPMSwtpmSetupFeature, VIR_TPM_SWTPM_SETUP_FEATURE_LAST, "cmdarg-pwdfile-fd", + "cmdarg-create-config-files", ); /** diff --git a/src/util/virtpm.h b/src/util/virtpm.h index d021a083b4..3bb03b3b33 100644 --- a/src/util/virtpm.h +++ b/src/util/virtpm.h @@ -38,6 +38,7 @@ typedef enum { typedef enum { VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD, + VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES, VIR_TPM_SWTPM_SETUP_FEATURE_LAST } virTPMSwtpmSetupFeature; -- 2.31.1

3 8

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

08 Oct '21

changelog: v7: Laine's suggestions from v6 incorporated. rebased the patchset to latest master. v6: rebased to latest. capabilities have been renamed as per suggestions that were made here: https://listman.redhat.com/archives/libvir-list/2021-October/msg00061.html 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 | 8 ++ docs/formatdomain.rst | 16 ++++ 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 | 20 +++++ 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, 515 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

2 6

Cancellation of VM core dumps
by Simon Rowe 08 Oct '21

08 Oct '21

I see that cancellation of core dump jobs that are memory-only are explicitly rejected >>> d.abortJob() libvirt: QEMU Driver error : Requested operation is not valid: cannot abort memory-only dump Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 544, in abortJob if ret == -1: raise libvirtError ('virDomainAbortJob() failed', dom=self) libvirt.libvirtError: Requested operation is not valid: cannot abort memory-only dump Is there a technical reason for this? Dumps of very large guests may take a long time and it would be useful to be able to abort them. Simon

2 1

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

08 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. I'm pretty unsure about the last patch in this series, given the impact it had on test data files. If it is indeed ok though, we can delete two capabilities too. v3: - Now with more fine grained patches and cleanups to avoid the bugs v2: - Now with cpu name compatibility retained Daniel P. Berrangé (6): qemu: always translate underscores to hyphens in CPU features qemu: always use hyphens in hyperv feature names qemu: remove use of (+|-)name syntax for -cpu featres qemu: inline the qemuBuildCpuFeature code qemu: remove use of implicit boolean syntax for guest features qemu: drop support for full CPU model expansion src/qemu/qemu_capabilities.c | 15 +- src/qemu/qemu_command.c | 46 +- src/qemu/qemu_monitor.h | 1 - src/qemu/qemu_monitor_json.c | 15 - .../caps_2.11.0.x86_64.replies | 2564 ++---------- .../caps_2.11.0.x86_64.xml | 182 +- .../caps_2.12.0.x86_64.replies | 3036 +++------------ .../caps_2.12.0.x86_64.xml | 194 +- .../caps_3.0.0.x86_64.replies | 3130 ++++----------- .../caps_3.0.0.x86_64.xml | 204 +- .../caps_3.1.0.x86_64.replies | 3436 ++++------------ .../caps_3.1.0.x86_64.xml | 218 +- .../caps_4.0.0.x86_64.replies | 3452 ++++------------- .../caps_4.0.0.x86_64.xml | 226 +- .../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-cmt.x86_64-4.0.0.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-2.11.0.args | 2 +- .../cpu-host-model.x86_64-2.12.0.args | 2 +- .../cpu-host-model.x86_64-3.0.0.args | 2 +- .../cpu-host-model.x86_64-3.1.0.args | 2 +- .../cpu-host-model.x86_64-4.0.0.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-4.0.0.args | 2 +- tests/qemuxml2argvdata/cpu-tsc-frequency.args | 2 +- .../cpu-tsc-frequency.x86_64-4.0.0.args | 2 +- .../eoi-disabled.x86_64-4.0.0.args | 2 +- .../eoi-enabled.x86_64-4.0.0.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-4.0.0.args | 2 +- tests/qemuxml2argvdata/kvmclock.args | 2 +- .../pci-bridge-many-disks.args | 2 +- .../pv-spinlock-disabled.x86_64-4.0.0.args | 2 +- .../pv-spinlock-enabled.x86_64-4.0.0.args | 2 +- 55 files changed, 3438 insertions(+), 13363 deletions(-) -- 2.31.1

2 12

[PATCH] qemu: tpm: Run swtpm_setup --create-config-files in session mode
by Stefan Berger 08 Oct '21

08 Oct '21

Using swtpm v0.7.0 we can run swtpm_setup to create default config files for swtpm_setup and swtpm-localca in session mode. Now a user can start a VM with an attached TPM without having to run this program on the command line before. This program needs to run once. This patch addresses the issue raised in https://bugzilla.redhat.com/show_bug.cgi?id=2010649 Sigbed-off-by: Stefan Berger <stefanb(a)linux.ibm.com> --- src/qemu/qemu_tpm.c | 43 +++++++++++++++++++++++++++++++++++++++++++ src/util/virtpm.c | 1 + src/util/virtpm.h | 1 + 3 files changed, 45 insertions(+) diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c index 100481503c..1b504bce67 100644 --- a/src/qemu/qemu_tpm.c +++ b/src/qemu/qemu_tpm.c @@ -385,6 +385,46 @@ qemuTPMSetupEncryption(const unsigned char *secretuuid, return virCommandSetSendBuffer(cmd, g_steal_pointer(&secret), secret_len); } + +/* + * qemuTPMCreateConfigFiles: run swtpm_setup --create-config-files skip-if-exist + * + * @logfile: The file to write the log into; it must be writable + * for the user given by userid or 'tss' + */ +static int +qemuTPMCreateConfigFiles(const char *logfile) +{ + g_autofree char *swtpm_setup = virTPMGetSwtpmSetup(); + g_autoptr(virCommand) cmd = NULL; + int exitstatus; + + if (!swtpm_setup) + return -1; + + if (!virTPMSwtpmSetupCapsGet( + VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES)) + return -1; + + cmd = virCommandNew(swtpm_setup); + if (!cmd) + return -1; + + virCommandAddArgList(cmd, "--create-config-files", "skip-if-exist", NULL); + virCommandClearCaps(cmd); + + if (virCommandRun(cmd, &exitstatus) < 0 || exitstatus != 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Could not run '%s' to create config files. exitstatus: %d; " + "Check error log '%s' for details."), + swtpm_setup, exitstatus, logfile); + return -1; + } + + return 0; +} + + /* * qemuTPMEmulatorRunSetup * @@ -432,6 +472,9 @@ qemuTPMEmulatorRunSetup(const char *storagepath, "this requires privileged mode for a " "TPM 1.2\n"), 0600); + if (!privileged && qemuTPMCreateConfigFiles(logfile)) + return -1; + cmd = virCommandNew(swtpm_setup); if (!cmd) return -1; diff --git a/src/util/virtpm.c b/src/util/virtpm.c index 1a567139b4..0f50de866c 100644 --- a/src/util/virtpm.c +++ b/src/util/virtpm.c @@ -45,6 +45,7 @@ VIR_ENUM_IMPL(virTPMSwtpmFeature, VIR_ENUM_IMPL(virTPMSwtpmSetupFeature, VIR_TPM_SWTPM_SETUP_FEATURE_LAST, "cmdarg-pwdfile-fd", + "cmdarg-create-config-files", ); /** diff --git a/src/util/virtpm.h b/src/util/virtpm.h index d021a083b4..3bb03b3b33 100644 --- a/src/util/virtpm.h +++ b/src/util/virtpm.h @@ -38,6 +38,7 @@ typedef enum { typedef enum { VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_PWDFILE_FD, + VIR_TPM_SWTPM_SETUP_FEATURE_CMDARG_CREATE_CONFIG_FILES, VIR_TPM_SWTPM_SETUP_FEATURE_LAST } virTPMSwtpmSetupFeature; -- 2.31.1

1 0

[PATCH] vireventglib: Remove handles with the highest priority
by Michal Privoznik 08 Oct '21

08 Oct '21

When a server decides to close a client, the virNetServerClientCloseLocked() is called. In here various cleanup steps are taken, but the most important part (from this commit's POV at least) is the way that the socket is closed. Firstly, removal of the socket associated with the client from the event loop is signalized and then the socket is unrefed. The socket is not closed just yet though, because the event loop holds a reference to it. This reference will be freed as soon as the event loop wakes up and starts issuing callbacks (in this case virNetSocketEventFree()). So far, this is how things usually work. But if the daemon reaches the number of opened files limit, things start to work differently. If the RLIMIT_NOFILE limit is reached and there's a client that wants to connect then the event loop wakes up, sees POLLIN on the socket and calls virNetServerServiceAccept() which in turn calls virNetSocketAccept(). But because of the limit, accept() fails with EMFILE leaving the POLLIN event unhandled. The dispatch then continues to next FDs with events on them. BUT, it will NOT call the socket removal callback (virNetSocketEventFree()) because it has low priority (G_PRIORITY_DEFAULT_IDLE). Per glib's documentation: * Each event source is assigned a priority. The default priority, * %G_PRIORITY_DEFAULT, is 0. Values less than 0 denote higher priorities. * Values greater than 0 denote lower priorities. Events from high priority * sources are always processed before events from lower priority sources. and per g_idle_add() documentation: * Adds a function to be called whenever there are no higher priority * events pending to the default main loop. The function is given the * default idle priority, %G_PRIORITY_DEFAULT_IDLE. Now, because we did not accept() the client we are constantly seeing POLLIN on the main socket and thus the removal of the client socket won't ever happen. The fix is to set at least the same priority as other sources, but since we want to just close an FD, let's give it the highest priority and call it before handling other events. This issue can be easily reproduced, for instance: # ulimit -S -n 40 (tweak this number if needed) # ./src/libvirtd from another terminal: # for ((i=0; i<100; i++)); do virsh list & done; virsh list The last `virsh list` must not get stuck. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2007168 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/vireventglib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/vireventglib.c b/src/util/vireventglib.c index f3e5a344b0..983787932f 100644 --- a/src/util/vireventglib.c +++ b/src/util/vireventglib.c @@ -287,7 +287,7 @@ virEventGLibHandleRemove(int watch) * 'removed' to prevent reuse */ data->removed = TRUE; - g_idle_add(virEventGLibHandleRemoveIdle, data); + g_idle_add_full(G_PRIORITY_HIGH, virEventGLibHandleRemoveIdle, data, NULL); ret = 0; -- 2.32.0

3 5

[PATCH] qemucapabilitiestest: Add test data for the qemu-6.2 development cycle
by Peter Krempa 08 Oct '21

08 Oct '21

The data is based on commit v6.1.0-1296-g14f12119aa Notable changes: - New machine types for the 6.2 cycle were added - MEM_UNPLUG_ERROR event was deprecated and replaced by DEVICE_UNPLUG_GUEST_ERROR - Intel SGX related commands and devices added - 'copy-before-write' blockdev filter was added - 'memory-backend-epc' was added - new cpu flags Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 220 + .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 226 + tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 220 + .../caps_6.2.0.x86_64.replies | 34119 ++++++++++++++++ .../caps_6.2.0.x86_64.xml | 3716 ++ 5 files changed, 38501 insertions(+) create mode 100644 tests/domaincapsdata/qemu_6.2.0-q35.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_6.2.0-tcg.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_6.2.0.x86_64.xml create mode 100644 tests/qemucapabilitiesdata/caps_6.2.0.x86_64.replies create mode 100644 tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml [...] diff --git a/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.replies b/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.replies new file mode 100644 index 0000000000..4e332ba861 --- /dev/null +++ b/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.replies @@ -0,0 +1,34119 @@ +{ + "execute": "qmp_capabilities", + "id": "libvirt-1" +} + +{ + "return": { + }, + "id": "libvirt-1" +} + +{ + "execute": "query-version", + "id": "libvirt-2" +} + +{ + "return": { + "qemu": { + "micro": 50, + "minor": 1, + "major": 6 + }, + "package": "v6.1.0-1296-g14f12119aa" + }, + "id": "libvirt-2" +} You can fetch the full patch at git fetch https://gitlab.com/pipo.sk/libvirt.git caps-6.2

2 1

[libvirt PATCH v3 0/5] add interface infomation in guestinfo command
by zhanglei 08 Oct '21

08 Oct '21

zhanglei (5): domain: add interface information to 'virDomainGetGuestInfo' virsh: add interface information to guestinfo command qemu: refactor 'qemuAgentGetInterfaces' qemu: add guest interface information in 'qemuDomainGetGuestInfo' NEWS: add guest interface information in 'virDomainGetGuestInfo' NEWS.rst | 5 ++ docs/manpages/virsh.rst | 12 ++++- include/libvirt/libvirt-domain.h | 1 + src/libvirt-domain.c | 12 +++++ src/qemu/qemu_agent.c | 9 ++-- src/qemu/qemu_agent.h | 3 +- src/qemu/qemu_driver.c | 90 +++++++++++++++++++++++++++++++- tests/qemuagenttest.c | 2 +- tools/virsh-domain.c | 6 +++ 9 files changed, 131 insertions(+), 9 deletions(-) -- 2.31.1

2 6

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

08 Oct '21

changelog: v6: rebased to latest. capabilities have been renamed as per suggestions that were made here: https://listman.redhat.com/archives/libvir-list/2021-October/msg00061.html 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

3 14

[PATCH] lxc: controller: Fix container launch on cgroup v1
by Cole Robinson 07 Oct '21

07 Oct '21

With cgroup v1 I'm seeing LXC container startup failures: $ sudo virt-install --connect lxc:/// --name test-container --memory 128 --boot init=/bin/sh Starting install... ERROR error from service: GDBus.Error:org.freedesktop.machine1.NoMachineForPID: PID 2145047 does not belong to any known machine libvirt 7.0.0 works but 7.1.0+ does not. The root error seems to predate that, showing up in syslog, but commit 9c1693eff made it fatal: commit 9c1693eff427661616ce1bd2795688f87288a412 Author: Pavel Hrdina <phrdina(a)redhat.com> Date: Fri Feb 5 16:17:35 2021 +0100 vircgroup: use DBus call to systemd for some APIs The error comes from virSystemdGetMachineByPID. The PID that shows up in the above error message does not match the leader PID as reported by machinectl. This change fixes the error. Things seem to continue to work with cgroupsv2 after this change. https://gitlab.com/libvirt/libvirt/-/issues/182 Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- This is from the thread in August, posted as non RFC now src/lxc/lxc_controller.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index 8953e0c904..444f728af4 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -865,12 +865,12 @@ static int virLXCControllerSetupCgroupLimits(virLXCController *ctrl) nodeset = virDomainNumatuneGetNodeset(ctrl->def->numa, auto_nodeset, -1); if (!(ctrl->cgroup = virLXCCgroupCreate(ctrl->def, - ctrl->initpid, + getpid(), ctrl->nnicindexes, ctrl->nicindexes))) goto cleanup; - if (virCgroupAddMachineProcess(ctrl->cgroup, getpid()) < 0) + if (virCgroupAddMachineProcess(ctrl->cgroup, ctrl->initpid) < 0) goto cleanup; /* Add all qemu-nbd tasks to the cgroup */ -- 2.31.1

3 2