April 2025 - Devel - libvirt List Archives

[PATCH] storage: virStorageVolDefParse and storageVolCreateXML flags fix
by Kirill Shchetiniuk 08 Apr '25

08 Apr '25

When the new storage was created using virsh with --validate option following errors occurred: # virsh vol-create default --file vol-def.xml --validate error: Failed to create vol from vol-def.xml error: unsupported flags (0x4) in function virStorageVolDefParseXML and after virStorageVolDefParse fix: # virsh vol-create default --file vol-def.xml --validate error: Failed to create vol from vol-def.xml error: unsupported flags (0x4) in function storageBackendCreateQemuImg Clear the VIR_STORAGE_VOL_CREATE_VALIDATE flag before virStorageVolDefParseXML and backend->buildVol (traces down to storageBackendCreateQemuImg) calls, as the XML schema validation is already complete within previous steps and there is no validation later. Signed-off-by: Kirill Shchetiniuk <kshcheti(a)redhat.com> --- NEWS.rst | 5 +++++ src/conf/storage_conf.c | 2 ++ src/storage/storage_driver.c | 4 +++- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/NEWS.rst b/NEWS.rst index e2dc4e508b..dd345bad7b 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -28,6 +28,11 @@ v11.3.0 (unreleased) * **Bug fixes** + * storage: Fix new volume creation + + No more errors occur when new storage volume is being created + using ``vol-create`` with ``--validate`` option. + v11.2.0 (2025-04-01) ==================== diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index 68842004b7..f6d804bb39 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -1409,6 +1409,8 @@ virStorageVolDefParse(virStoragePoolDef *pool, "volume", &ctxt, "storagevol.rng", validate))) return NULL; + flags &= ~(VIR_STORAGE_VOL_CREATE_VALIDATE); + return virStorageVolDefParseXML(pool, ctxt, flags); } diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 86c03762d2..2f5a26bbef 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -1877,6 +1877,7 @@ storageVolCreateXML(virStoragePoolPtr pool, virStorageVolPtr vol = NULL, newvol = NULL; g_autoptr(virStorageVolDef) voldef = NULL; unsigned int parseFlags = VIR_VOL_XML_PARSE_OPT_CAPACITY; + unsigned int buildFlags = flags; virCheckFlags(VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA | VIR_STORAGE_VOL_CREATE_VALIDATE, NULL); @@ -1953,8 +1954,8 @@ storageVolCreateXML(virStoragePoolPtr pool, voldef->building = true; virObjectUnlock(obj); - buildret = backend->buildVol(obj, buildvoldef, flags); + buildFlags &= ~(VIR_STORAGE_VOL_CREATE_VALIDATE); + buildret = backend->buildVol(obj, buildvoldef, buildFlags); VIR_FREE(buildvoldef); -- 2.48.1

3 8

[PATCH 0/4] qemu: Remove legacy 'nbd-export-add' code and deprecate corresponding capabilities
by Peter Krempa 08 Apr '25

08 Apr '25

Peter Krempa (4): qemu: block: Always assume support for 'block-export-add' qemu: monitor: Drop wrappers for 'nbd-server-add' qemu: capabilities: Retire QEMU_CAPS_BLOCK_EXPORT_ADD qemu: capabilities: Retire QEMU_CAPS_NBD_BITMAP src/qemu/qemu_block.c | 7 ----- src/qemu/qemu_capabilities.c | 6 ++-- src/qemu/qemu_capabilities.h | 4 +-- src/qemu/qemu_monitor.c | 17 ----------- src/qemu/qemu_monitor.h | 5 ---- src/qemu/qemu_monitor_json.c | 28 ------------------- src/qemu/qemu_monitor_json.h | 6 ---- .../caps_10.0.0_s390x.xml | 2 -- .../caps_10.0.0_x86_64+amdsev.xml | 2 -- .../caps_10.0.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 2 -- .../caps_6.2.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 2 -- .../caps_7.0.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 2 -- .../caps_7.1.0_x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 2 -- .../caps_7.2.0_x86_64+hvf.xml | 2 -- .../caps_7.2.0_x86_64.xml | 2 -- .../caps_8.0.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 2 -- .../caps_8.1.0_x86_64.xml | 2 -- .../caps_8.2.0_aarch64.xml | 2 -- .../caps_8.2.0_armv7l.xml | 2 -- .../caps_8.2.0_loongarch64.xml | 2 -- .../qemucapabilitiesdata/caps_8.2.0_s390x.xml | 2 -- .../caps_8.2.0_x86_64.xml | 2 -- .../qemucapabilitiesdata/caps_9.0.0_sparc.xml | 2 -- .../caps_9.0.0_x86_64.xml | 2 -- .../caps_9.1.0_riscv64.xml | 2 -- .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 2 -- .../caps_9.1.0_x86_64.xml | 2 -- .../caps_9.2.0_aarch64+hvf.xml | 2 -- .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 2 -- .../caps_9.2.0_x86_64+amdsev.xml | 2 -- .../caps_9.2.0_x86_64.xml | 2 -- tests/qemumonitorjsontest.c | 2 -- 37 files changed, 4 insertions(+), 129 deletions(-) -- 2.49.0

2 5

[PATCH] docs: drvqemu: Fix required minimum qemu version to 6.2.0
by Peter Krempa 08 Apr '25

08 Apr '25

From: Peter Krempa <pkrempa(a)redhat.com> Commit 8824af826d3 (and also commit 073bf167843 before it) which bumped minimu, qemu version forgot to update the qemu driver documentation page Fixes: 8824af826d3 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/drvqemu.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drvqemu.rst b/docs/drvqemu.rst index e52d9ffd47..796aae587c 100644 --- a/docs/drvqemu.rst +++ b/docs/drvqemu.rst @@ -5,7 +5,7 @@ QEMU/KVM/HVF hypervisor driver ============================== -The libvirt KVM/QEMU driver can manage any QEMU emulator from version 4.2.0 or +The libvirt KVM/QEMU driver can manage any QEMU emulator from version 6.2.0 or later. It supports multiple QEMU accelerators: software -- 2.49.0

2 1

[PATCH v2 0/2] derpecate some block-job- APIs
by Vladimir Sementsov-Ogievskiy 08 Apr '25

08 Apr '25

v2: Update documentation: add patch 01 v1 was: [PATCH] [for-10.1] qapi/block-core: derpecate some block-job- APIs Supersedes: <20250401155730.103718-1-vsementsov(a)yandex-team.ru> Vladimir Sementsov-Ogievskiy (2): qapi: synchronize jobs and block-jobs documentation qapi/block-core: derpecate some block-job- APIs docs/about/deprecated.rst | 31 ++++++++++++++ qapi/block-core.json | 89 ++++++++++++++++++++++++++++----------- qapi/job.json | 29 ++++++++++++- 3 files changed, 122 insertions(+), 27 deletions(-) -- 2.48.1

3 7

[PATCH] qemu: rdp: Fix 'qemuRdpAvailable()'
by Peter Krempa 08 Apr '25

08 Apr '25

From: Peter Krempa <pkrempa(a)redhat.com> qemuRdpAvailable() is called from the capability filing code, thus: - it must not report spurious errors - it should not call any extra processes We can solve the above by just checking existance of 'qemu-rdp' in the path as: - at the time of adding of qemuRdpAvailable() there was only one 'qemu-rdp' release - it supported all the features - the check can't change as we'd drop the capability Add comments and gut the check to only check existance of the file. Fixes: f5e5a9bec9ec3e6c762f5000e3b8a0ba6a3a8c8d Closes: https://gitlab.com/libvirt/libvirt/-/issues/763 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_rdp.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_rdp.c b/src/qemu/qemu_rdp.c index 984795d599..0c48b87e7b 100644 --- a/src/qemu/qemu_rdp.c +++ b/src/qemu/qemu_rdp.c @@ -413,12 +413,25 @@ qemuRdpSetCredentials(virDomainObj *vm, } +/** + * qemuRdpAvailable: + * @helper: name (or path to) 'qemu-rdp' binary + * + * Returns whether 'qemu-rdp' is available. + * + * Important: + * This function is called from 'virQEMUDriverGetDomainCapabilities'. It must + * not report any errors and must not add any additional checks. + * + * This function is mocked from 'tests/testutilsqemu.c' + * + */ bool qemuRdpAvailable(const char *helper) { - g_autoptr(qemuRdp) rdp = NULL; - - rdp = qemuRdpNewForHelper(helper); + g_autofree char *helperPath = NULL; - return rdp && qemuRdpHasFeature(rdp, QEMU_RDP_FEATURE_DBUS_ADDRESS); + /* This function was added corresponding to the first release of 'qemu-rdp' + * thus checking existance of the helper binary is sufficient. */ + return !!(helperPath = virFindFileInPath(helper)); } -- 2.49.0

3 2

Re: [PATCH v8 55/55] docs: Add TDX documentation
by Daniel P. Berrangé 08 Apr '25

08 Apr '25

CC libvirt / Jiri, for confirmation about whether the CPUID restrictions listed below will have any possible impact on libvirt CPUID handling... On Tue, Apr 01, 2025 at 09:02:05AM -0400, Xiaoyao Li wrote: > Add docs/system/i386/tdx.rst for TDX support, and add tdx in > confidential-guest-support.rst > > Signed-off-by: Xiaoyao Li <xiaoyao.li(a)intel.com> > --- > Changes in v6: > - Add more information of "Feature configuration" > - Mark TD Attestation as future work because KVM now drops the support > of it. > > Changes in v5: > - Add TD attestation section and update the QEMU parameter; > > Changes since v1: > - Add prerequisite of private gmem; > - update example command to launch TD; > > Changes since RFC v4: > - add the restriction that kernel-irqchip must be split > --- > docs/system/confidential-guest-support.rst | 1 + > docs/system/i386/tdx.rst | 156 +++++++++++++++++++++ > docs/system/target-i386.rst | 1 + > 3 files changed, 158 insertions(+) > create mode 100644 docs/system/i386/tdx.rst > +Feature Configuration > +--------------------- > + > +Unlike non-TDX VM, the CPU features (enumerated by CPU or MSR) of a TD are not > +under full control of VMM. VMM can only configure part of features of a TD on > +``KVM_TDX_INIT_VM`` command of VM scope ``MEMORY_ENCRYPT_OP`` ioctl. > + > +The configurable features have three types: > + > +- Attributes: > + - PKS (bit 30) controls whether Supervisor Protection Keys is exposed to TD, > + which determines related CPUID bit and CR4 bit; > + - PERFMON (bit 63) controls whether PMU is exposed to TD. > + > +- XSAVE related features (XFAM): > + XFAM is a 64b mask, which has the same format as XCR0 or IA32_XSS MSR. It > + determines the set of extended features available for use by the guest TD. > + > +- CPUID features: > + Only some bits of some CPUID leaves are directly configurable by VMM. > + > +What features can be configured is reported via TDX capabilities. > + > +TDX capabilities > +~~~~~~~~~~~~~~~~ > + > +The VM scope ``MEMORY_ENCRYPT_OP`` ioctl provides command ``KVM_TDX_CAPABILITIES`` > +to get the TDX capabilities from KVM. It returns a data structure of > +``struct kvm_tdx_capabilities``, which tells the supported configuration of > +attributes, XFAM and CPUIDs. > + > +TD attributes > +~~~~~~~~~~~~~ > + > +QEMU supports configuring raw 64-bit TD attributes directly via "attributes" > +property of "tdx-guest" object. Note, it's users' responsibility to provide a > +valid value because some bits may not supported by current QEMU or KVM yet. > + > +QEMU also supports the configuration of individual attribute bits that are > +supported by it, via properties of "tdx-guest" object. > +E.g., "sept-ve-disable" (bit 28). > + > +MSR based features > +~~~~~~~~~~~~~~~~~~ > + > +Current KVM doesn't support MSR based feature (e.g., MSR_IA32_ARCH_CAPABILITIES) > +configuration for TDX, and it's a future work to enable it in QEMU when KVM adds > +support of it. > + > +Feature check > +~~~~~~~~~~~~~ > + > +QEMU checks if the final (CPU) features, determined by given cpu model and > +explicit feature adjustment of "+featureA/-featureB", can be supported or not. > +It can produce feature not supported warning like > + > + "warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]" > + > +It can also produce warning like > + > + "warning: TDX forcibly sets the feature: CPUID.80000007H:EDX.invtsc [bit 8]" > + > +if the fixed-1 feature is requested to be disabled explicitly. This is newly > +added to QEMU for TDX because TDX has fixed-1 features that are forcibly enabled > +by TDX module and VMM cannot disable them. This is where I'm wondering if libvirt has anything to be concerned about. Possibly when libvirt queries the actual CPUID after launching the guest it will just "do the right thing" ? Wondering if there's any need for libvirt to be aware of CPUID restrictions before that point though ? > + > +Launching a TD (TDX VM) > +----------------------- > + > +To launch a TD, the necessary command line options are tdx-guest object and > +split kernel-irqchip, as below: > + > +.. parsed-literal:: > + > + |qemu_system_x86| \\ > + -object tdx-guest,id=tdx0 \\ > + -machine ...,kernel-irqchip=split,confidential-guest-support=tdx0 \\ > + -bios OVMF.fd \\ I don't think we need to show 'kernel-irqchip=split' now that we "do the right thing" by default This surely also ought to include '-accel kvm', as IIUC there's no TCG support for TDX. And presumably '-cpu host', since QEMU's default 'qemu64' CPU model is likely a terrible match for what TDX will force set. > + > +Restrictions > +------------ > + > + - kernel-irqchip must be split; Can append "This is set by default for TDX guests if kernel-irqchip is left on its default 'auto' setting." > + > + - No readonly support for private memory; > + > + - No SMM support: SMM support requires manipulating the guest register states > + which is not allowed; > + With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

3 2

[PATCH v3 00/20] Add qemu RDP server support
by marcandre.lureau＠redhat.com 07 Apr '25

07 Apr '25

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, This patch series offers an out-of-process Remote Desktop Protocol (RDP) server solution utilizing QEMU's -display dbus interface, offering improved modularity and potential security benefits compared to built-in server. This initiative was spearheaded by Mihnea Buzatu during the QEMU Summer of Code 2023. The project's goal was to develop an out-of-process RDP server using the -display dbus interface, implemented in Rust. Given that the IronRDP crate lacked some server support at the time, investments in IronRDP were required. I finally released an initial v0.1 version of qemu-rdp on crates.io (https://crates.io/crates/qemu-rdp) That should allow more people to review and evaluate the state of this work. On unix systems, with cargo/rust toolchain installed, it should be as easy as running "cargo install qemu-rdp", apply this patch series for libvirt, set the "rdp_tls_x509_cert_dir" location for your TLS certificates, and configure a VM with both dbus & rdp graphics (run "virsh domdisplay DOMAIN" to get the display connection details). Thanks for the reviews & feedback! v3: thanks to Martin Kletzander review - drop "[PATCH v2 05/21] qemu: fall-through for unsupported graphics" patch - drop extra \n when reporting dbus-daemon log - check password != NULL or VIR_ERR_INTERNAL_ERROR - remove some needless #include/leftover - remove some needless g_auto pointer - rebased - add r-b tags v2: thanks to Daniel review - drop extra error report from "qemu: report an error for unsupported graphics" - replace g_return pre-conditions with ATTRIBUTE_NONNULL - improve "qemu/dbus: keep a connection to the VM D-Bus" to also reconnect - use domainLogContext for logging (for virtiofs as well) - check for qemu-rdp availabilty for setting 'rdp' capability - make dbus-addr qemu-rdp capability mandatory - rebased - add r-b tags Marc-André Lureau (20): build-sys: drop -Winline when optimization=g build: fix -Werror=maybe-uninitialized qemu-slirp: drop unneeded check for OOM util: annotate non-null arguments for virGDBusCallMethod() qemu: add rdp state directory qemu: add qemu RDP configuration conf: parse optional RDP username & password conf: generalize virDomainDefHasSpiceGraphics qemu: use virDomainDefHasGraphics qemu: add RDP ports range allocator qemu: limit to one <graphics type='rdp'> qemu/virtiofs: use domainLogContext qemu/dbus: keep a connection to the VM D-Bus qemu/dbus: log daemon stdout/err, use domainLogContext qemu: validate RDP configuration qemu: add qemu-rdp helper unit qemu: pass virQEMUDriverConfig to capabilities qemu: add 'rdp' capability if qemu-rdp is available qemu: add RDP support tests: add qemu <graphics type='rdp'/> test docs/formatdomain.rst | 25 +- meson.build | 7 +- po/POTFILES | 1 + src/conf/domain_conf.c | 28 +- src/conf/domain_conf.h | 5 +- src/conf/schemas/domaincommon.rng | 10 + src/libvirt_private.syms | 2 +- src/qemu/libvirtd_qemu.aug | 7 + src/qemu/meson.build | 1 + src/qemu/qemu.conf.in | 31 ++ src/qemu/qemu_capabilities.c | 24 +- src/qemu/qemu_capabilities.h | 12 +- src/qemu/qemu_command.c | 8 +- src/qemu/qemu_conf.c | 56 ++- src/qemu/qemu_conf.h | 13 + src/qemu/qemu_dbus.c | 69 ++- src/qemu/qemu_dbus.h | 3 + src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 4 + src/qemu/qemu_driver.c | 20 + src/qemu/qemu_extdevice.c | 46 +- src/qemu/qemu_hotplug.c | 51 ++- src/qemu/qemu_hotplug.h | 1 + src/qemu/qemu_process.c | 169 ++++++- src/qemu/qemu_rdp.c | 424 ++++++++++++++++++ src/qemu/qemu_rdp.h | 73 +++ src/qemu/qemu_slirp.c | 6 - src/qemu/qemu_validate.c | 48 +- src/qemu/qemu_virtiofs.c | 53 +-- src/qemu/test_libvirtd_qemu.aug.in | 5 + src/util/virgdbus.h | 13 +- .../qemu_10.0.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 1 + .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_10.0.0.s390x.xml | 1 + .../qemu_10.0.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 1 + .../qemu_7.2.0-hvf.x86_64+hvf.xml | 1 + .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 1 + .../qemu_7.2.0-tcg.x86_64+hvf.xml | 1 + .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.2.0.ppc.xml | 1 + tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 1 + .../qemu_8.2.0-tcg-virt.loongarch64.xml | 1 + .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 1 + .../qemu_8.2.0-virt.aarch64.xml | 1 + .../qemu_8.2.0-virt.loongarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 1 + tests/domaincapsdata/qemu_8.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.0.0.sparc.xml | 1 + tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 1 + .../qemu_9.1.0-tcg-virt.riscv64.xml | 1 + .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 1 + .../qemu_9.1.0-virt.riscv64.xml | 1 + tests/domaincapsdata/qemu_9.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 1 + .../qemu_9.2.0-hvf.aarch64+hvf.xml | 1 + .../qemu_9.2.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 1 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.2.0.s390x.xml | 1 + .../qemu_9.2.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 1 + tests/domaincapstest.c | 7 +- .../graphics-rdp.x86_64-latest.args | 35 ++ .../graphics-rdp.x86_64-latest.xml | 1 + tests/qemuxmlconfdata/graphics-rdp.xml | 43 ++ tests/qemuxmlconftest.c | 2 + tests/testutilsqemu.c | 10 + tools/nss/libvirt_nss_leases.c | 2 +- tools/nss/libvirt_nss_macs.c | 2 +- 92 files changed, 1234 insertions(+), 137 deletions(-) create mode 100644 src/qemu/qemu_rdp.c create mode 100644 src/qemu/qemu_rdp.h create mode 100644 tests/qemuxmlconfdata/graphics-rdp.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/graphics-rdp.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/graphics-rdp.xml -- 2.47.0

5 26

[PATCH 0/3] cpu_map: Install Ampere-1 ARM CPU models
by Jiri Denemark 07 Apr '25

07 Apr '25

BTW, the added test will not actually detect similar issues in the future (I'm thinking about such test, though), but it will help with other issues with the ARM CPU map as it hasn't been covered at all. Jiri Denemark (3): tests: Add a basic CPU test for aarch64 cpu_map: Install Ampere-1 ARM CPU models NEWS: Document ARM CPU map bug fix NEWS.rst | 6 +++++ src/cpu_map/meson.build | 2 ++ tests/cputest.c | 35 +++++++++++++++++++++++++++++ tests/cputestdata/aarch64-guest.xml | 4 ++++ 4 files changed, 47 insertions(+) create mode 100644 tests/cputestdata/aarch64-guest.xml -- 2.49.0

4 6

[PATCH v1 00/18] LIBVIRT: X86: TDX support
by Zhenzhong Duan 07 Apr '25

07 Apr '25

Hi, This series brings libvirt the x86 TDX support. * What's TDX? TDX stands for Trust Domain Extensions which isolates VMs from the virtual-machine manager (VMM)/hypervisor and any other software on the platform. This patchset extends libvirt to support TDX, with which one can start a TDX guest from high level rather than running qemu directly. * Misc As QEMU use a software emulated way to reset guest which isn't supported by TDX guest for security reason. We simulate reboot for TDX guest by kill and create a new one in FakeReboot framework. Complete code can be found at [1], matching qemu code can be found at [2]. There is a 'QGS' element for attestation which isn't in matching qemu[2] yet. I keep them intentionally as they will be implemented in qemu as extention series of [2]. * Test start/stop/reboot/reset with virsh stop/reboot trigger in guest stop with on_poweroff=destroy/restart reboot with on_reboot=destroy/restart * Patch organization - patch 1-4: Support query of TDX capabilities - patch 5-11: Add TDX type to launchsecurity framework - patch 12-17: Add reboot/reset support to TDX guest - patch 18: Add docs TODO: - add reconnect logic in virsh command [1] https://github.com/intel/libvirt-tdx/commits/tdx_for_upstream_v1 [2] https://github.com/intel-staging/qemu-tdx/tree/tdx-qemu-upstream-v8 Thanks Zhenzhong Changelog: v1: - s/virQEMUCapsKVMSupportsSecureGuestINTEL/virQEMUCapsKVMSupportsSecureGuestTDX (Daniel) - make policy element optional and expose to QEMU directly (Daniel) - s/qemuProcessSecFakeReboot/qemuProcessFakeRebootViaRecreate (Daniel) - simplify QGS element schema by supporting only UNIX socket (Daniel) - add new events VIR_DOMAIN_EVENT_[STOPPED|STARTED] for control plane (Daniel) - s/quoteGenerationService/quoteGenerationSocket as QEMU - add virsh reset support rfcv4: - add a check to tools/virt-host-validate-qemu.c (Daniel) - remove check of q35 (Daniel) - model 'SocktetAddress' QAPI in xml schema (Daniel) - s/Quote-Generation-Service/quoteGenerationService/ (Daniel) - define bits in tdx->policy and add validating logic (Daniel) - presume QEMU choose split kernel irqchip for TDX guest by default (Daniel) - utilize existing FakeReboot framework to do reboot for TDX guest (Daniel) - drop patch11 'conf: Add support to keep same domid for hard reboot' (Daniel) - add test in tests/ to validate parsing and formatting logic (Daniel) - add doc in docs/formatdomain.rst (Daniel) - add R-B rfcv3: - Change to generate qemu cmdline with -bios - drop firmware auto match as -bios is used - add a hard reboot method to reboot TDX guest rfcv3: https://www.mail-archive.com/devel@lists.libvirt.org/msg00385.html rfcv2: - give up using qmp cmd and check TDX directly on host for TDX capabilities. - use launchsecurity framework to support TDX - use <os>.<loader> for general loader - add auto firmware match feature for TDX A example TDVF fimware description file 70-edk2-x86_64-tdx.json: { "description": "UEFI firmware for x86_64, supporting Intel TDX", "interface-types": [ "uefi" ], "mapping": { "device": "generic", "filename": "/usr/share/OVMF/OVMF_CODE-tdx.fd" }, "targets": [ { "architecture": "x86_64", "machines": [ "pc-q35-*" ] } ], "features": [ "intel-tdx", "verbose-dynamic" ], "tags": [ ] } rfcv2: https://www.mail-archive.com/libvir-list@redhat.com/msg219378.html Zhenzhong Duan (18): tools: Secure guest check for Intel in virt-host-validate qemu: Check if INTEL Trust Domain Extention support is enabled qemu: Add TDX capability conf: Expose TDX feature in domain capabilities conf: Add tdx as launch security type conf: Validate TDX launchSecurity element mrConfigId/mrOwner/mrOwnerConfig qemu: Add command line and validation for TDX type conf: Expose TDX type in domain launch security capability qemu: Force special parameters enabled for TDX guest conf: Add Intel TDX Quote Generation Service(QGS) support qemu: Add command line for TDX Quote Generation Service(QGS) qemu: Add FakeReboot support for TDX guest qemu: Support reboot command in guest qemu: Avoid duplicate FakeReboot for secure guest qemu: Send event VIR_DOMAIN_EVENT_[STOPPED|STARTED] during recreation qemu: Bypass sending VIR_DOMAIN_EVENT_RESUMED event when TD VM reboot qemu: Support domain reset command for TDX guest docs: domain: Add documentation for Intel TDX guest docs/formatdomain.rst | 63 ++++++++++++++++++ docs/formatdomaincaps.rst | 1 + examples/c/misc/event-test.c | 6 ++ include/libvirt/libvirt-domain.h | 2 + src/conf/domain_capabilities.c | 1 + src/conf/domain_capabilities.h | 1 + src/conf/domain_conf.c | 82 +++++++++++++++++++++++ src/conf/domain_conf.h | 21 ++++++ src/conf/domain_validate.c | 11 ++++ src/conf/schemas/domaincaps.rng | 9 +++ src/conf/schemas/domaincommon.rng | 41 ++++++++++++ src/conf/virconftypes.h | 2 + src/qemu/qemu_capabilities.c | 38 ++++++++++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 1 + src/qemu/qemu_command.c | 54 +++++++++++++++ src/qemu/qemu_driver.c | 7 ++ src/qemu/qemu_firmware.c | 1 + src/qemu/qemu_monitor.c | 28 +++++++- src/qemu/qemu_monitor.h | 2 +- src/qemu/qemu_monitor_json.c | 6 +- src/qemu/qemu_namespace.c | 1 + src/qemu/qemu_process.c | 105 ++++++++++++++++++++++++++++-- src/qemu/qemu_process.h | 2 + src/qemu/qemu_validate.c | 45 +++++++++++++ src/security/security_dac.c | 2 + tools/virsh-domain-event.c | 6 +- tools/virt-host-validate-common.c | 31 ++++++++- tools/virt-host-validate-common.h | 1 + 29 files changed, 558 insertions(+), 13 deletions(-) -- 2.34.1

3 20

[PATCH] [for-10.1] qapi/block-core: derpecate some block-job- APIs
by Vladimir Sementsov-Ogievskiy 05 Apr '25

05 Apr '25

For change, pause, resume, complete, dismiss and finalize actions corresponding job- and block-job commands are almost equal. The difference is in find_block_job_locked() vs find_job_locked() functions. What's different? 1. find_block_job_locked() do check, is found job a block-job. This OK when moving to more generic API, no needs to document this change. 2. find_block_job_locked() reports DeviceNotActive on failure, when find_job_locked() reports GenericError. So, lets document this difference in deprecated.txt. Still, for dismiss and finalize errors are not documented at all, so be silent in deprecated.txt as well. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov(a)yandex-team.ru> --- Hi all! That's a continuation of my "[RFC 00/15] block job API"[1], exactly, the simplest part of it - deprecating block-job-* commands which simply duplicate job-* ones. Note that the old series was started with trying to introduce job-change command as substitution to both block-job-change (which only can change mirror copy-mode parameter), and block-job-set-speed. It was rather complicated and controversial attempt, which latest implemenation was "[PATCH v3 0/7] introduce job-change qmp command"[2]. In [2] Kevin noted, that we'd better follow existing blockdev-reopen approach of changing options (i.e. specify all options) than introduce a new one. But, on the other hand, now I'm afraid, that rewriting in third tools simple call to (old good) block-job-set-speed into job-change(_all_options_ + changed speed) is too much work just for "having nice interface". And too much for the only two options we want to change. So, let's just start from something more obvious. Finally, we can simple keep block-job-set-speed and block-job-change as is, as they (unlike other block-job-* commands) are not duplicated by similar job-* commands. [1] https://patchew.org/QEMU/20240313150907.623462-1-vsementsov@yandex-team.ru/ [2] https://patchew.org/QEMU/20241002140616.561652-1-vsementsov@yandex-team.ru/ docs/about/deprecated.rst | 31 +++++++++++++++++++++++++++++++ qapi/block-core.json | 30 ++++++++++++++++++++++++++++++ 2 files changed, 61 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index e2b4f077d4..eed3356359 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -148,6 +148,37 @@ options are removed in favor of using explicit ``blockdev-create`` and ``blockdev-add`` calls. See :doc:`/interop/live-block-operations` for details. +``block-job-pause`` (since 10.1) +''''''''''''''''''''''''''''''' + +Use ``job-pause`` instead. The only difference is that ``job-pause`` +always reports GenericError on failure when ``block-job-pause`` reports +DeviceNotActive when block-job is not found. + +``block-job-resume`` (since 10.1) +'''''''''''''''''''''''''''''''' + +Use ``job-resume`` instead. The only difference is that ``job-resume`` +always reports GenericError on failure when ``block-job-resume`` reports +DeviceNotActive when block-job is not found. + +``block-job-complete`` (since 10.1) +'''''''''''''''''''''''''''''''''' + +Use ``job-complete`` instead. The only difference is that ``job-complete`` +always reports GenericError on failure when ``block-job-complete`` reports +DeviceNotActive when block-job is not found. + +``block-job-dismiss`` (since 10.1) +''''''''''''''''''''''''''''''''' + +Use ``job-dismiss`` instead. + +``block-job-finalize`` (since 10.1) +'''''''''''''''''''''''''''''''''' + +Use ``job-finalize`` instead. + ``query-migrationthreads`` (since 9.2) '''''''''''''''''''''''''''''''''''''' diff --git a/qapi/block-core.json b/qapi/block-core.json index b1937780e1..264be8413b 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -2968,6 +2968,11 @@ # the name of the parameter), but since QEMU 2.7 it can have other # values. # +# Features: +# +# @deprecated: This command is deprecated. Use @job-pause +# instead. +# # Errors: # - If no background operation is active on this device, # DeviceNotActive @@ -2975,6 +2980,7 @@ # Since: 1.3 ## { 'command': 'block-job-pause', 'data': { 'device': 'str' }, + 'features': ['deprecated'], 'allow-preconfig': true } ## @@ -2992,6 +2998,11 @@ # the name of the parameter), but since QEMU 2.7 it can have other # values. # +# Features: +# +# @deprecated: This command is deprecated. Use @job-resume +# instead. +# # Errors: # - If no background operation is active on this device, # DeviceNotActive @@ -2999,6 +3010,7 @@ # Since: 1.3 ## { 'command': 'block-job-resume', 'data': { 'device': 'str' }, + 'features': ['deprecated'], 'allow-preconfig': true } ## @@ -3023,6 +3035,11 @@ # the name of the parameter), but since QEMU 2.7 it can have other # values. # +# Features: +# +# @deprecated: This command is deprecated. Use @job-complete +# instead. +# # Errors: # - If no background operation is active on this device, # DeviceNotActive @@ -3030,6 +3047,7 @@ # Since: 1.3 ## { 'command': 'block-job-complete', 'data': { 'device': 'str' }, + 'features': ['deprecated'], 'allow-preconfig': true } ## @@ -3047,9 +3065,15 @@ # # @id: The job identifier. # +# Features: +# +# @deprecated: This command is deprecated. Use @job-dismiss +# instead. +# # Since: 2.12 ## { 'command': 'block-job-dismiss', 'data': { 'id': 'str' }, + 'features': ['deprecated'], 'allow-preconfig': true } ## @@ -3064,9 +3088,15 @@ # # @id: The job identifier. # +# Features: +# +# @deprecated: This command is deprecated. Use @job-finalize +# instead. +# # Since: 2.12 ## { 'command': 'block-job-finalize', 'data': { 'id': 'str' }, + 'features': ['deprecated'], 'allow-preconfig': true } ## -- 2.48.1

3 6