March 2025 - Devel - libvirt List Archives

[PATCH] qemu: snapshot: Remove dead code in qemuSnapshotDeleteBlockJobFinishing()
by Alexander Kuznetsov 06 Mar '25

06 Mar '25

qemuSnapshotDeleteBlockJobFinishing() returns only 0 and 1. Convert it to bool and remove the dead code handling -1 return in the caller. Found by Linux Verification Center (linuxtesting.org) with Svace. Reported-by: Reported-by: Andrey Slepykh <a.slepykh(a)fobos-nt.ru> Signed-off-by: Alexander Kuznetsov <kuznetsovam(a)altlinux.org> --- src/qemu/qemu_snapshot.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 80cd54bf33..d277f76b4b 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -3465,7 +3465,7 @@ qemuSnapshotDeleteBlockJobIsRunning(qemuBlockjobState state) /* When finishing or aborting qemu blockjob we only need to know if the * job is still active or not. */ -static int +static bool qemuSnapshotDeleteBlockJobIsActive(qemuBlockjobState state) { switch (state) { @@ -3475,7 +3475,7 @@ qemuSnapshotDeleteBlockJobIsActive(qemuBlockjobState state) case QEMU_BLOCKJOB_STATE_ABORTING: case QEMU_BLOCKJOB_STATE_PENDING: case QEMU_BLOCKJOB_STATE_PIVOTING: - return 1; + return true; case QEMU_BLOCKJOB_STATE_COMPLETED: case QEMU_BLOCKJOB_STATE_FAILED: @@ -3485,7 +3485,7 @@ qemuSnapshotDeleteBlockJobIsActive(qemuBlockjobState state) break; } - return 0; + return false; } @@ -3513,18 +3513,14 @@ static int qemuSnapshotDeleteBlockJobFinishing(virDomainObj *vm, qemuBlockJobData *job) { - int rc; qemuBlockJobUpdate(vm, job, VIR_ASYNC_JOB_SNAPSHOT); - while ((rc = qemuSnapshotDeleteBlockJobIsActive(job->state)) > 0) { + while (qemuSnapshotDeleteBlockJobIsActive(job->state)) { if (qemuDomainObjWait(vm) < 0) return -1; qemuBlockJobUpdate(vm, job, VIR_ASYNC_JOB_SNAPSHOT); } - if (rc < 0) - return -1; - return 0; } -- 2.42.4

2 2

[PATCH 0/2] ch: minor fixes - segfault fix and error preserving
by Kirill Shchetiniuk 06 Mar '25

06 Mar '25

*** BLURB HERE *** Kirill Shchetiniuk (2): ch: memory (segmentation fault) fix ch: preserve last error before stop fix src/ch/ch_events.c | 6 +++--- src/ch/ch_process.c | 6 ++++++ 2 files changed, 9 insertions(+), 3 deletions(-) -- 2.48.1

3 5

[PATCH pushed] domain_caps: Don't leak 'cpu0_id' in 'virSEVCapabilitiesFree'
by Peter Krempa 06 Mar '25

06 Mar '25

Freeing the 'virSEVCapability' object leaked the 'cpu0_id' field since its introduction. Fixes: 0236e6154c46603bc443eda2f05c8ce511c55b08 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- Trivial and fixed build. src/conf/domain_capabilities.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c index ab715b19d8..27551f6102 100644 --- a/src/conf/domain_capabilities.c +++ b/src/conf/domain_capabilities.c @@ -75,6 +75,7 @@ virSEVCapabilitiesFree(virSEVCapability *cap) g_free(cap->pdh); g_free(cap->cert_chain); + g_free(cap->cpu0_id); g_free(cap); } -- 2.48.1

1 0

[PATCH v2 0/7] Add support for more ACPI table types
by Daniel P. Berrangé 06 Mar '25

06 Mar '25

This was triggered by a request by KubeVirt in https://gitlab.com/libvirt/libvirt/-/issues/748 I've not functionally tested this, since I lack any suitable guest windows environment this is looking for MSDM tables, nor does my machine have MSDM ACPI tables to pass to a guest. I'm blindly assuming that the QEMU CLI code is identical except for s/SLIC/MSDM/. In this 2nd version I've addressed two further issues * the xen driver was incorrectly mapping its 'acpi_firmware' option to type=slic. Xen's setting accepts a concatenation of tables of any type. This is different from type=slic which represents a single table, whose type will be forced to 'SLIC' if not already set. To address this we introduce a new 'rawset' type * The QEMU driver does not require a type to be set in the first place; if set it merely overrides what is in the data file. Supporting this would let us handle any ACPI table type without further XML changes. To address this we introduce a new 'raw' type, which can occur many times. Daniel P. Berrangé (7): conf: introduce support for multiple ACPI tables src: validate permitted ACPI table types in libxl/qemu drivers src: introduce 'raw' and 'rawset' ACPI table types qemu: support 'raw' ACPI table type libxl: support 'rawset' ACPI table type conf: support MSDM ACPI table type qemu: support MSDM ACPI table type docs/formatdomain.rst | 23 ++++- src/conf/domain_conf.c | 94 ++++++++++++++----- src/conf/domain_conf.h | 24 ++++- src/conf/schemas/domaincommon.rng | 7 +- src/libvirt_private.syms | 2 + src/libxl/libxl_conf.c | 5 +- src/libxl/libxl_domain.c | 28 ++++++ src/libxl/xen_xl.c | 15 ++- src/qemu/qemu_command.c | 18 +++- src/qemu/qemu_validate.c | 23 +++++ src/security/security_dac.c | 18 ++-- src/security/security_selinux.c | 16 ++-- src/security/virt-aa-helper.c | 5 +- .../acpi-table-many.x86_64-latest.args | 37 ++++++++ .../acpi-table-many.x86_64-latest.xml | 42 +++++++++ tests/qemuxmlconfdata/acpi-table-many.xml | 34 +++++++ tests/qemuxmlconftest.c | 1 + .../xlconfigdata/test-fullvirt-acpi-slic.xml | 2 +- 18 files changed, 337 insertions(+), 57 deletions(-) create mode 100644 tests/qemuxmlconfdata/acpi-table-many.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/acpi-table-many.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/acpi-table-many.xml -- 2.47.1

2 9

[PATCH] Fix a typo in docs/formatdomain.rst
by Yalan Zhang 06 Mar '25

06 Mar '25

Fix a typo and update the setting in the example. The documentation explains that "when passt is the backend,...the ``<source>`` path/type/mode are all implied to be "matching the passt process" so **must not** be specified." Additionally, this source dev setting is ignored in practice. Therefore, let's remove it from the example to avoid any confusion. Signed-off-by: Yalan Zhang <yalzhang(a)redhat.com> --- docs/formatdomain.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index cbe378e61d..e84e0a0e8e 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -5154,7 +5154,7 @@ destined for the host toward the guest instead), and a socket between passt and QEMU forwards that traffic on to the guest (and back out, of course). -*(:since:`Since 11.1.0 (QEMU and KVM only)` you may prefer to use the +:since:`Since 11.1.0 (QEMU and KVM only)` you may prefer to use the passt backend with the more efficient and performant type='vhostuser' rather than type='user'. All the options related to passt in the paragraphs below here also apply when using the passt backend with @@ -6378,7 +6378,6 @@ setting guest-side IP addresses with ``<ip>`` and port forwarding with <interface type='vhostuser'> <backend type='passt'/> <mac address='52:54:00:3b:83:1a'/> - <source dev='enp1s0'/> <ip address='10.30.0.5 prefix='24'/> </interface> </devices> -- 2.48.1

3 4

[PATCH 0/5] Introduce UEFI shim support
by Michal Privoznik 06 Mar '25

06 Mar '25

*** BLURB HERE *** Michal Prívozník (5): conf: Introduce os/shim element qemu_capabilities: Introduce QEMU_CAPS_MACHINE_SHIM qemu_validate: Check whether UEFI shim is supported qemu_command: Generate cmd line for UEFI shim security: Set seclabels on UEFI shim docs/formatdomain.rst | 5 +++++ src/conf/domain_conf.c | 12 ++++++++---- src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 6 ++++++ src/conf/schemas/domaincommon.rng | 5 +++++ src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 2 ++ src/qemu/qemu_validate.c | 7 +++++++ src/security/security_dac.c | 10 ++++++++++ src/security/security_selinux.c | 9 +++++++++ src/security/virt-aa-helper.c | 4 ++++ tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml | 1 + tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 1 + .../launch-security-sev-direct.x86_64-latest.args | 1 + .../launch-security-sev-direct.x86_64-latest.xml | 1 + tests/qemuxmlconfdata/launch-security-sev-direct.xml | 1 + 17 files changed, 65 insertions(+), 4 deletions(-) -- 2.45.3

2 6

[PATCH 0/8] qemu: Follow-up to "schemas: domaincaps: Add missing schema for '<cpu0Id>'"
by Peter Krempa 04 Mar '25

04 Mar '25

As promised in the original patch fixing the schema this is the test-case follow up. As not entirely expected it's a bit more involved and also contains fixes for other bugs. Peter Krempa (8): qemu: capabilities: Parse 'cpu0Id' from capability cache XML domaincapstest: Use proper input file based on 'variant' in 'fillQemuCaps' domaincapstest: Allow tests of all capability variants qemucapabilitiesdata: Document '+amdsev' variant qemucapabilitiestest: Add test data for 'qemu-9.2' on a SEV-enabled AMD host qemuxmlconftest: Propery discriminate output files for caps variants qemuxmlconftest: Add 'latest' version of 'launch-security-sev*' originally using 6.0.0 qemuxmlconftest: Add '+amdsev' versions of the rest of 'launch-security-sev*' cases src/qemu/qemu_capabilities.c | 1 + .../qemu_7.0.0-hvf.aarch64+hvf.xml | 43 +- .../qemu_7.2.0-hvf.x86_64+hvf.xml | 952 +- .../qemu_9.2.0-q35.x86_64+amdsev.xml | 852 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 1821 + .../qemu_9.2.0.x86_64+amdsev.xml | 852 + tests/domaincapstest.c | 21 +- tests/qemucapabilitiesdata/README.rst | 4 + .../caps_9.2.0_x86_64+amdsev.replies | 43857 ++++++++++++++++ .../caps_9.2.0_x86_64+amdsev.xml | 3132 ++ .../caps.x86_64+amdsev.xml | 29 + ...h64-virt-headless.aarch64-latest+hvf.args} | 0 ...ch64-virt-headless.aarch64-latest+hvf.xml} | 0 ...86_64-q35-headless.x86_64-latest+hvf.args} | 0 ...x86_64-q35-headless.x86_64-latest+hvf.xml} | 0 ...urity-sev-direct.x86_64-latest+amdsev.args | 38 + ...curity-sev-direct.x86_64-latest+amdsev.xml | 48 + ...ng-platform-info.x86_64-latest+amdsev.args | 35 + ...ing-platform-info.x86_64-latest+amdsev.xml | 43 + ...security-sev-snp.x86_64-latest+amdsev.args | 42 + ...-security-sev-snp.x86_64-latest+amdsev.xml | 73 + ...nch-security-sev.x86_64-latest+amdsev.args | 35 + ...unch-security-sev.x86_64-latest+amdsev.xml | 45 + tests/qemuxmlconftest.c | 40 +- tests/testutilsqemu.c | 6 +- 25 files changed, 51941 insertions(+), 28 deletions(-) create mode 100644 tests/domaincapsdata/qemu_9.2.0-q35.x86_64+amdsev.xml create mode 100644 tests/domaincapsdata/qemu_9.2.0-tcg.x86_64+amdsev.xml create mode 100644 tests/domaincapsdata/qemu_9.2.0.x86_64+amdsev.xml create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_x86_64+amdsev.replies create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_x86_64+amdsev.xml create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+amdsev.xml rename tests/qemuxmlconfdata/{hvf-aarch64-virt-headless.aarch64-latest.args => hvf-aarch64-virt-headless.aarch64-latest+hvf.args} (100%) rename tests/qemuxmlconfdata/{hvf-aarch64-virt-headless.aarch64-latest.xml => hvf-aarch64-virt-headless.aarch64-latest+hvf.xml} (100%) rename tests/qemuxmlconfdata/{hvf-x86_64-q35-headless.x86_64-latest.args => hvf-x86_64-q35-headless.x86_64-latest+hvf.args} (100%) rename tests/qemuxmlconfdata/{hvf-x86_64-q35-headless.x86_64-latest.xml => hvf-x86_64-q35-headless.x86_64-latest+hvf.xml} (100%) create mode 100644 tests/qemuxmlconfdata/launch-security-sev-direct.x86_64-latest+amdsev.args create mode 100644 tests/qemuxmlconfdata/launch-security-sev-direct.x86_64-latest+amdsev.xml create mode 100644 tests/qemuxmlconfdata/launch-security-sev-missing-platform-info.x86_64-latest+amdsev.args create mode 100644 tests/qemuxmlconfdata/launch-security-sev-missing-platform-info.x86_64-latest+amdsev.xml create mode 100644 tests/qemuxmlconfdata/launch-security-sev-snp.x86_64-latest+amdsev.args create mode 100644 tests/qemuxmlconfdata/launch-security-sev-snp.x86_64-latest+amdsev.xml create mode 100644 tests/qemuxmlconfdata/launch-security-sev.x86_64-latest+amdsev.args create mode 100644 tests/qemuxmlconfdata/launch-security-sev.x86_64-latest+amdsev.xml -- 2.48.1

2 9

[PATCH] docs/api.rst: revert erroneously change of Once -> OnDevice
by Cleber Rosa 04 Mar '25

04 Mar '25

Commit af1b89d1d for some reason changed a perfectly fine statement to one that I could not understand. Let's revert it. Signed-off-by: Cleber Rosa <crosa(a)redhat.com> --- docs/api.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/api.rst b/docs/api.rst index cdba642967..243303de68 100644 --- a/docs/api.rst +++ b/docs/api.rst @@ -26,7 +26,7 @@ name will default to a preselected hypervisor, but it's probably not a wise thing to do in most cases. See the `connection URI <uri.html>`__ page for a full descriptions of the values allowed. -OnDevice the application obtains a +Once the application obtains a `virConnectPtr <html/libvirt-libvirt-host.html#virConnectPtr>`__ connection to the hypervisor it can then use it to manage the hypervisor's available domains and related virtualization resources, -- 2.48.1

2 1

[PATCH] schemas: domaincaps: Add missing schema for '<cpu0Id>'
by Peter Krempa 03 Mar '25

03 Mar '25

Fixes: 0236e6154c46603bc443eda2f05c8ce511c55b08 Resolves: https://issues.redhat.com/browse/RHEL-81890 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- I'll also attempt to add tests for this once I'll be able to get to a capability dump from a sev-es enabled box. src/conf/schemas/domaincaps.rng | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/conf/schemas/domaincaps.rng b/src/conf/schemas/domaincaps.rng index 3559d2ae05..595dbcd634 100644 --- a/src/conf/schemas/domaincaps.rng +++ b/src/conf/schemas/domaincaps.rng @@ -438,6 +438,11 @@ <data type="unsignedInt"/> </element> </optional> + <optional> + <element name="cpu0Id"> + <data type="string"/> + </element> + </optional> </element> </define> -- 2.48.1

2 1

[PATCH] qemuPrepareNVRAMFile: Fix NVRAM image conversion check
by Peter Krempa 03 Mar '25

03 Mar '25

In case when user provides custom paths (those not covered by the JSON firmware descriptor files or the default locations) for the loader and nvram template no auto-detection will be performed and user's config will be taken at face value. Historically when 'templateFormat' didn't exist we assumed that the 'format' field covers both. Thus if 'templateFormat' is VIR_STORAGE_FILE_NONE we need to skip the check forbidding image format conversion for 'file' backed to avoid breaking legacy configs with manual/non-detected format assuming that user picked the correct format. Add a comment to the declaration of 'nvramTemplateFormat' noting the above for future reference. Resolves: https://issues.redhat.com/browse/RHEL-81731 Fixes: 2aa644a2fc8 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/conf/domain_conf.h | 7 +++++++ src/qemu/qemu_process.c | 5 ++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index d4fa79cb84..1fcc3fdb98 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -2362,6 +2362,13 @@ struct _virDomainLoaderDef { virStorageSource *nvram; bool newStyleNVRAM; char *nvramTemplate; /* user override of path to master nvram */ + /* Historically it was assumed that the format of the template and the + * actual nvram image are identical, which is no longer true. + * + * Note: if 'nvramTemplate' comes from the user and is not overriden by + * auto-detection nvramTemplateFormat may be VIR_STORAGE_FILE_NONE. Code + * shall assume that the template format matches if it isn't provided. + */ virStorageFileFormat nvramTemplateFormat; }; diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 0d9b8bcb93..7b7b5c17e3 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4709,7 +4709,10 @@ qemuPrepareNVRAMFile(virQEMUDriver *driver, return -1; } - if (loader->nvram->format != loader->nvramTemplateFormat) { + /* If 'nvramTemplateFormat' is empty it means that it's a user-provided + * template which we couldn't verify. Assume the user knows what they're doing */ + if (loader->nvramTemplateFormat != VIR_STORAGE_FILE_NONE && + loader->nvram->format != loader->nvramTemplateFormat) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", _("conversion of the nvram template to another target format is not supported")); return -1; -- 2.48.1

2 1