December 2025 - Devel - libvirt List Archives

Re: Question about error conditions for ACPI usage on aarch64
by Andrea Bolognani 09 Jan '26

09 Jan '26

On Mon, Dec 15, 2025 at 07:08:28AM +0000, Kazuhiro Abe (Fujitsu) wrote: > > On Tue, Dec 02, 2025 at 12:52:02AM +0000, Kazuhiro Abe (Fujitsu) wrote: > > > > You've just identified one of those issues that I predicted I would > > > > run into and have to fix :) > > > > > > > > I already have a patch addressing that, among other things, > > > > in my local branch. I expect to be able to post the whole > > > > series shortly, probably next week. > > > > > > It would be great if you can share the updates of your patch. > > > > Still working on it :) It's taking a bit longer than I had anticipated to get all the > > ducks in a row, but I'm hoping that I will be able to finally post the series this > > week or the next one. > > When can we expect this patch to be ready? > We would appreciate it if you could provide us with this information as soon as possible. I plan have patches on the list by the end of the week. -- Andrea Bolognani / Red Hat / Virtualization

2 5

[PATCH v4 00/23] LIBVIRT: X86: TDX support
by Zhenzhong Duan 07 Jan '26

07 Jan '26

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]. * Test Tested with upstream qemu v10.0.0-1724-gf9a3def17b shutdown/reboot/reset with virsh shutdown/reboot trigger in guest shutdown with on_poweroff=destroy/restart reboot with on_reboot=destroy/restart GUEST_PANICKED event processing auto firmware matching * Patch organization - patch 1-4: Some preparing work - patch 5-6: Support query of TDX capabilities - patch 7-15: Add TDX type to launchsecurity framework - patch 16-21: Add reboot/reset support to TDX guest - patch 22: Add conf test dump/cases for '+inteltdx' variant - patch 23: Add docs TODO: - add reconnect logic in virsh command [1] https://github.com/intel/libvirt-tdx/commits/tdx_for_upstream_v4 Thanks Zhenzhong Changelog: v4: - add QGS config to qemuxmlconftest (Daniel) - use 0x10000000 policy value in test as debug isn't supported yet (Daniel) - s/mrowner/mrOwner/ s/mrownerconfig/mrOwnerConfig/ (Daniel) - s/quoteGenerationSocket/quoteGenerationService/ (Daniel) - handle "GUEST_PANICKED" event of type tdx (Daniel) - add automatic firmware matching (Daniel) v3: - fix a hiden failure in qemuBuildTDXQGSCommandLine() (Peter Krempa) - avoid the use of the ternary operator (Peter Krempa) - add capability test dump before capability introduced (Peter Krempa) - change tests version number from 11.0.0 to 10.1.0 (Peter Krempa) v2: - add capability and xmlconf test (Peter Krempa) 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 (23): tools: Secure guest check for Intel in virt-host-validate qemu: Check if INTEL Trust Domain Extention support is enabled qemucapabilitiesdata: Document '+inteltdx' variant qemucapabilitiestest: Add data for the qemu-10.1.0 dev cycle on x86_64 for the '+inteltdx' variant qemu: Add QEMU_CAPS_TDX_GUEST 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 qemu: log the crash information for TDX qemu_firmware: Pick the right firmware for TDX guests 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 qemuxmlconftest: Add latest version of 'launch-security-tdx*' test data 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 | 43 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 11 +- src/qemu/qemu_firmware.c | 20 + src/qemu/qemu_monitor.c | 50 +- src/qemu/qemu_monitor.h | 13 +- src/qemu/qemu_monitor_json.c | 38 +- src/qemu/qemu_namespace.c | 1 + src/qemu/qemu_process.c | 104 +- src/qemu/qemu_process.h | 2 + src/qemu/qemu_validate.c | 45 + src/security/security_dac.c | 2 + .../qemu_10.1.0-q35.x86_64+inteltdx.xml | 783 + .../domaincapsdata/qemu_10.1.0-q35.x86_64.xml | 7 +- .../qemu_10.1.0-tcg.x86_64+inteltdx.xml | 1830 + .../domaincapsdata/qemu_10.1.0-tcg.x86_64.xml | 6 +- .../qemu_10.1.0.x86_64+inteltdx.xml | 783 + tests/domaincapsdata/qemu_10.1.0.x86_64.xml | 7 +- tests/domaincapsmock.c | 3 +- tests/qemucapabilitiesdata/README.rst | 5 + .../caps_10.1.0_x86_64+inteltdx.replies | 44552 ++++++++++++++++ .../caps_10.1.0_x86_64+inteltdx.xml | 3585 ++ .../caps_10.1.0_x86_64.xml | 1 + .../caps.x86_64+inteltdx.xml | 29 + .../firmware/60-edk2-ovmf-x64-inteltdx.json | 1 + ...h-security-tdx.x86_64-latest+inteltdx.args | 44 + ...ch-security-tdx.x86_64-latest+inteltdx.xml | 75 + tests/qemuxmlconfdata/launch-security-tdx.xml | 28 + tests/qemuxmlconftest.c | 3 + tools/virsh-domain-event.c | 6 +- tools/virt-host-validate-common.c | 31 +- tools/virt-host-validate-common.h | 1 + 47 files changed, 52372 insertions(+), 18 deletions(-) create mode 100644 tests/domaincapsdata/qemu_10.1.0-q35.x86_64+inteltdx.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0-tcg.x86_64+inteltdx.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0.x86_64+inteltdx.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_x86_64+inteltdx.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_x86_64+inteltdx.xml create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+inteltdx.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.x86_64-latest+inteltdx.args create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.x86_64-latest+inteltdx.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.xml -- 2.47.1

4 39

[PATCH] qemu: Add stop hook support for domain shutdown
by Mitchel Humpherys 06 Jan '26

06 Jan '26

Introduce a new QEMU hook operation "stop" that is called before a domain is terminated (via virsh shutdown or virsh destroy). This allows external scripts to perform cleanup or veto the stop process by returning a non-zero exit code. The hook is called as: /etc/libvirt/hooks/qemu <guest_name> stop begin - The full domain XML is provided on stdin. Example qemu hook that protects domains from being stopped (to be dropped in /etc/libfirt/hooks/qemu.d/10-vm-protection or similar): ```bash #!/bin/bash # Protection hook - vetos domain stops for domains listed in # /etc/libvirt/protected-domains set -euo pipefail readonly PROTECT_DIR="/etc/libvirt" readonly DOMAIN_NAME="${1:-}" readonly OPERATION="${2:-}" # Only act on stop operation if [[ "$OPERATION" != "stop" ]]; then exit 0 fi readonly PROTECT_LIST="${PROTECT_DIR}/protected-domains" if [[ -f "$PROTECT_LIST" ]]; then # Read file, strip comments and empty lines, check for exact domain match if grep -Fxq -- "$DOMAIN_NAME" <(sed -e 's/#.*$//' -e '/^[[:space:]]*$/d' "$PROTECT_LIST"); then logger -t libvirt-hook-test "20-protection: BLOCKING stop for protected domain '$DOMAIN_NAME'" echo "$(date '+%Y-%m-%d %H:%M:%S'): BLOCKED stop for '$DOMAIN_NAME'" \ >> /tmp/libvirt-test-logs/protection.log printf 'vm-protection: stop blocked for %s\n' "$DOMAIN_NAME" >&2 exit 1 fi fi exit 0 ``` With a list of domains to protect in /etc/libvirt/protected-domains. With the above hook in place, attempting to destroy a domain listed in /etc/libvirt/protected-domains will fail: ``` > virsh list --all Id Name State ------------------------------- 2 protected-vm running - test-vm shut off > virsh destroy protected-vm error: Failed to destroy domain 'protected-vm' error: Hook script execution failed: internal error: Child process (LC_ALL=C LD_LIBRARY_PATH=/opt/libvirt-test/lib/x86_64-linux-gnu:/opt/libvirt-test/lib PATH=/usr/local/sbin:/usr/local/bin:/usr/bin HOME=/root USER=root LOGNAME=root /opt/libvirt-test/etc/libvirt/hooks/qemu.d/20-protection protected-vm stop begin -) unexpected exit status 1: vm-protection: stop blocked for protected-vm > virsh list --all Id Name State ------------------------------- 2 protected-vm running - test-vm shut off ``` Signed-off-by: Mitchel Humpherys <mitch.special(a)gmail.com> --- docs/hooks.rst | 14 +++++++++++--- src/qemu/qemu_process.c | 17 +++++++++++++++++ src/util/virhook.c | 1 + src/util/virhook.h | 1 + 4 files changed, 30 insertions(+), 3 deletions(-) diff --git a/docs/hooks.rst b/docs/hooks.rst index e1745b8cc7..5ae03a36cd 100644 --- a/docs/hooks.rst +++ b/docs/hooks.rst @@ -202,9 +202,17 @@ operation. There is no specific operation to indicate a "restart" is occurring. /etc/libvirt/hooks/qemu guest_name started begin - -- When a QEMU guest is stopped, the qemu hook script is called in two - locations, to match the startup. First, :since:`since 0.8.0`, the hook is - called before libvirt restores any labels: +- When a QEMU guest is stopped, the qemu hook script is called in three + locations, to match the startup. The first location, :since:`since 11.10.0`, + is called before the domain is stopped. This allows the hook to perform + cleanup tasks or veto the stop operation by returning a non-zero exit code: + + :: + + /etc/libvirt/hooks/qemu guest_name stop begin - + + The second location, :since:`since 0.8.0`, is called after the QEMU process + has terminated but before libvirt restores any labels: :: diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 0e50cd1ccc..fa2b691d99 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -9015,6 +9015,23 @@ qemuProcessBeginStopJob(virDomainObj *vm, qemuDomainObjPrivate *priv = vm->privateData; unsigned int killFlags = forceKill ? VIR_QEMU_PROCESS_KILL_FORCE : 0; + /* call stop hook if present */ + if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) { + virQEMUDriver *driver = priv->driver; + g_autofree char *xml = qemuDomainDefFormatXML(driver, NULL, vm->def, 0); + int hookret; + + if (!xml) + return -1; + + hookret = virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, + VIR_HOOK_QEMU_OP_STOP, VIR_HOOK_SUBOP_BEGIN, + NULL, xml, NULL); + + if (hookret < 0) + return -1; + } + /* We need to prevent monitor EOF callback from doing our work (and * sending misleading events) while the vm is unlocked inside * BeginJob/ProcessKill API or any other code path before 'vm->def->id' is diff --git a/src/util/virhook.c b/src/util/virhook.c index d012bb1825..01ba17e406 100644 --- a/src/util/virhook.c +++ b/src/util/virhook.c @@ -76,6 +76,7 @@ VIR_ENUM_IMPL(virHookSubop, VIR_ENUM_IMPL(virHookQemuOp, VIR_HOOK_QEMU_OP_LAST, "start", + "stop", "stopped", "prepare", "release", diff --git a/src/util/virhook.h b/src/util/virhook.h index d8237c837e..ea8c540c3f 100644 --- a/src/util/virhook.h +++ b/src/util/virhook.h @@ -52,6 +52,7 @@ typedef enum { typedef enum { VIR_HOOK_QEMU_OP_START, /* domain is about to start */ + VIR_HOOK_QEMU_OP_STOP, /* domain is about to stop */ VIR_HOOK_QEMU_OP_STOPPED, /* domain has stopped */ VIR_HOOK_QEMU_OP_PREPARE, /* domain startup initiated */ VIR_HOOK_QEMU_OP_RELEASE, /* domain destruction is over */ -- 2.52.0

2 2

[PATCH 00/10] qemu: Snapshot and saveimage related refactors (background snapshot saga part 2)
by Peter Krempa 06 Jan '26

06 Jan '26

This series fixes up some code (mostly removes unneeded) 'driver' argument and fixes control flow in some snapshot and save image related functions. This series also contains 2 patches necromanced from the original attempt to add background snapshot from Nikolay. Nikolay Shirokovskiy (2): qemu: snapshot: Don't overwrite 'ret' in qemuSnapshotCreateActiveExternal qemu: snapshot: Check earlier if memory snapshot is possible Peter Krempa (8): qemuHotplugAttachDBusVMState: Remove 'driver' argument qemuMigrationSrcToLegacyFile: Remove 'driver' argument qemuDomainEventEmitJobCompleted: Remove 'driver' argument qemuMigrationSrcToSparseFile: Remove 'driver' argument qemuMigrationSrcToFile: Remove 'driver' argument qemuSaveImageCreateFd: Remove 'driver' argument qemuSaveImageCreate: Remove 'driver' argument virQEMUSaveDataNew: Refactor cleanup src/qemu/qemu_backup.c | 2 +- src/qemu/qemu_domainjob.c | 6 +++--- src/qemu/qemu_domainjob.h | 3 +-- src/qemu/qemu_driver.c | 4 ++-- src/qemu/qemu_hotplug.c | 6 ++---- src/qemu/qemu_hotplug.h | 3 +-- src/qemu/qemu_migration.c | 36 ++++++++++++++++++------------------ src/qemu/qemu_migration.h | 5 ++--- src/qemu/qemu_saveimage.c | 27 ++++++++++++--------------- src/qemu/qemu_saveimage.h | 3 +-- src/qemu/qemu_snapshot.c | 22 ++++++++++++---------- 11 files changed, 55 insertions(+), 62 deletions(-) -- 2.52.0

3 13

[PATCH v4 0/9] Enable mshv support for Qemu domains
by Praveen K Paladugu 06 Jan '26

06 Jan '26

This patch set introduces changes within libvirt to lauch Qemu guests with Microsoft Hypervisor(mshv). Qemu exposes this capability as 'mshv' accelerator type. Below is an excerpt of domain XML with mshv accelerator.: ``` <domain type='hyperv'> <name>qemu_mshv_test</name> <os> <type machine='q35'>hvm</type> </os> ... ``` 'mshv' accelerator within Qemu translates to 'hyperv' domains in Libvirt. Changs in v4: - Adopted `query-accelerators` API to get mshv capabilities. - Fixed virtytpe parsing in schemas. Chages in v3: - Addressed review comments on v2. - fixed qemucapabilitiestest case - Added a case to qemuxmlconftest Changes in v2: - Addressed review comments on v1. - Added a test to verify mshv capabilities. Eugene Fedorenko (1): qemu: Append mshv to hwaccel list. Praveen K Paladugu (8): qemu: Introduce mshv capabilities qemu: Query and use mshv capabilities qemu: use mshv accel for hyperv domains qemu: conditionally add /dev/mshv to acl conf: Fix virttype handling in schemas tests: Add domaincaps case for mshv tests: qemucapabilities: Introduce MSHV capability tests:qemuxmlconftest: Add case for hyperv domains src/conf/schemas/basictypes.rng | 22 + src/conf/schemas/capability.rng | 14 +- src/conf/schemas/domaincommon.rng | 23 +- src/qemu/qemu_capabilities.c | 39 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 6 + src/qemu/qemu_command.c | 4 +- src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 2 +- .../qemu_10.2.0-q35.x86_64+mshv.xml | 222 + .../qemu_10.2.0-tcg.x86_64+mshv.xml | 2334 + .../qemu_10.2.0.x86_64+mshv.xml | 222 + .../caps_10.2.0_x86_64+mshv.replies | 45176 ++++++++++++++++ .../caps_10.2.0_x86_64+mshv.xml | 3212 ++ .../qemucaps2xmloutdata/caps.x86_64+mshv.xml | 29 + ...86_64-q35-headless.x86_64-latest+mshv.args | 48 + ...x86_64-q35-headless.x86_64-latest+mshv.xml | 87 + ...mshv-x86_64-q35-headless.x86_64-latest.err | 1 + .../mshv-x86_64-q35-headless.xml | 35 + tests/qemuxmlconftest.c | 5 + 20 files changed, 51446 insertions(+), 38 deletions(-) create mode 100644 tests/domaincapsdata/qemu_10.2.0-q35.x86_64+mshv.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0-tcg.x86_64+mshv.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0.x86_64+mshv.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.2.0_x86_64+mshv.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.2.0_x86_64+mshv.xml create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+mshv.xml create mode 100644 tests/qemuxmlconfdata/mshv-x86_64-q35-headless.x86_64-latest+mshv.args create mode 100644 tests/qemuxmlconfdata/mshv-x86_64-q35-headless.x86_64-latest+mshv.xml create mode 100644 tests/qemuxmlconfdata/mshv-x86_64-q35-headless.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/mshv-x86_64-q35-headless.xml -- 2.51.0

4 24

[PATCH] libvirt-guests.service: use Type=exec
by Antonio Terceiro 06 Jan '26

06 Jan '26

Type=oneshot means that the service is only considered started after the main process exits. In setups where libvirt-guests is configured to be used and imposes a delay on the startup of guests, this will cause systemd to report a quite high boot time as it will wait until all guests have booted, plus all the delay between them. High boot times are often reported as issues in monitoring systems, and require operator attention, while in this case there is not really an issue with the system, it's just doing what it was configured to do. With Type=exec, the service is considered started right after the main process is *started*, but the boot process will not wait for it. Having other units depend on libvirt-guests.service finishing was already not reliable because one cannot know how long the OS inside each guest takes to boot, and libvirt-guests already does not wait for them to be in any particular state. Signed-off-by: Antonio Terceiro <terceiro(a)debian.org> --- tools/libvirt-guests.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libvirt-guests.service.in b/tools/libvirt-guests.service.in index b044444298..c8e4d3d749 100644 --- a/tools/libvirt-guests.service.in +++ b/tools/libvirt-guests.service.in @@ -19,7 +19,7 @@ EnvironmentFile=-@initconfdir@/libvirt-guests # out the code ExecStart=@libexecdir@/libvirt-guests.sh start ExecStop=@libexecdir@/libvirt-guests.sh stop -Type=oneshot +Type=exec RemainAfterExit=yes StandardOutput=journal+console TimeoutStopSec=0 -- 2.51.0

3 4

[PATCH 00/36] qemu: Improvements and fixes to firmware selection
by Andrea Bolognani 06 Jan '26

06 Jan '26

This series improves validation so that more nonsensical configurations are rejected, fixes a number of scenarios in which user-provided attributes were getting overwritten by the firmware selection process, and overall makes things more predictable and reliable. Notably, it addresses the inability of starting confidential VMs on aarch64, which was reported[1] some time ago. It is also a prerequisite of another series that I will post shortly, which introduces support for the uefi-vars QEMU device and thus makes it possible to use Secure Boot for aarch64 VMs. Since all these fixes and improvements make sense on their own, and there is a little bit of work still needed on the QEMU/edk2 side before the other series can be merged, I decided to post this one separately instead of lumping them together. It's not like it's not meaty enough on its own anyway :) [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/D5UD… Andrea Bolognani (36): qemu_firmware: Drop support for kernel descriptors qemu_firmware: Drop 'nvram' local variable qemu_firmware: Move format=raw compat exception qemu_firmware: Move copying of nvram.format to loader.format tests: Add firmware-manual-efi-rw-nvram domain_validate: Reject NVRAM with read/write firmware tests: Add firmware-auto-bios-rw tests: Add firmware-manual-bios-rw domain_validate: Reject read/write ROMs tests: Add firmware-auto-efi-format-loader-qcow2-rom domain_validate: Reject ROMs with format other than raw qemu_firmware: Ignore stateless/combined when NVRAM is configured qemu_firmware: Drop fallback for absent nvramTemplateFormat schemas: Allow templateFormat without template path tests: Add firmware-manual-efi-nvram-template-nonstandard-format tests: Add firmware-manual-efi-nvram-template-nonstandard-legacy-paths tests: Add firmware-auto-efi-format-nvram-raw tests: Add firmware-auto-efi-format-nvram-raw-loader-path tests: Add firmware-auto-efi-format-nvram-raw-nvramtemplate-path tests: Add firmware-auto-efi-format-nvramtemplate-qcow2 tests: Add firmware-auto-efi-format-mismatch-nvramtemplate qemu_firmware: Introduce qemuFirmwareFillDomainCustom() qemu_firmware: Set templateFormat for custom paths qemu_firmware: Simplify handling of legacy paths qemu_firmware: Refactor setting NVRAM format qemu_firmware: Prefer template format to loader format qemu_firmware: Retain user-specified NVRAM format qemu_firmware: Take templateFormat into account when matching qemu_firmware: Take NVRAM format into account when matching qemu_firmware: Remove NVRAM to loader format copy hack tests: Add firmware-manual-efi-sev-snp tests: Add firmware-manual-efi-tdx qemu_firmware: ROM firmware is always in raw format qemu_firmware: Don't skip autoselection for ROM qemu_firmware: Allow matching both UEFI and BIOS for ROM loader news: Mention improvements and fixes to firmware selection NEWS.rst | 8 + src/conf/domain_conf.c | 18 +- src/conf/domain_validate.c | 30 ++ src/conf/schemas/domaincommon.rng | 10 +- src/qemu/qemu_firmware.c | 367 ++++++++++-------- src/qemu/qemu_postparse.c | 17 - .../firmware-auto-bios-rw.x86_64-latest.err | 1 + ...> firmware-auto-bios-rw.x86_64-latest.xml} | 5 +- .../qemuxmlconfdata/firmware-auto-bios-rw.xml | 18 + ...-format-loader-qcow2-rom.x86_64-latest.err | 1 + ...mware-auto-efi-format-loader-qcow2-rom.xml | 18 + ...t-mismatch-nvramtemplate.x86_64-latest.err | 1 + ...-mismatch-nvramtemplate.x86_64-latest.xml} | 6 +- ...auto-efi-format-mismatch-nvramtemplate.xml | 19 + ...uto-efi-format-mismatch.x86_64-latest.args | 5 +- ...auto-efi-format-mismatch.x86_64-latest.xml | 2 +- ...-nvram-raw-loader-path.x86_64-latest.args} | 4 +- ...t-nvram-raw-loader-path.x86_64-latest.xml} | 4 +- ...-auto-efi-format-nvram-raw-loader-path.xml | 19 + ...raw-nvramtemplate-path.x86_64-latest.args} | 4 +- ...-raw-nvramtemplate-path.x86_64-latest.xml} | 4 +- ...fi-format-nvram-raw-nvramtemplate-path.xml | 18 + ...t-nvram-raw.x86_64-latest.abi-update.args} | 0 ...at-nvram-raw.x86_64-latest.abi-update.xml} | 0 ...o-efi-format-nvram-raw.x86_64-latest.args} | 0 ...to-efi-format-nvram-raw.x86_64-latest.xml} | 0 .../firmware-auto-efi-format-nvram-raw.xml | 18 + ...at-nvramtemplate-qcow2.x86_64-latest.args} | 9 +- ...mat-nvramtemplate-qcow2.x86_64-latest.xml} | 4 +- ...re-auto-efi-format-nvramtemplate-qcow2.xml | 18 + .../firmware-manual-bios-rw.x86_64-latest.err | 1 + .../firmware-manual-bios-rw.xml | 15 + ...-loader-path-nonstandard.x86_64-latest.xml | 2 +- ...ate-nonstandard-format.x86_64-latest.args} | 10 +- ...late-nonstandard-format.x86_64-latest.xml} | 4 +- ...-efi-nvram-template-nonstandard-format.xml | 19 + ...nstandard-legacy-paths.x86_64-latest.args} | 4 +- ...onstandard-legacy-paths.x86_64-latest.xml} | 5 +- ...vram-template-nonstandard-legacy-paths.xml | 20 + ...ram-template-nonstandard.x86_64-latest.xml | 2 +- ...ware-manual-efi-rw-nvram.x86_64-latest.err | 1 + .../firmware-manual-efi-rw-nvram.xml | 19 + ...ual-efi-sev-snp.x86_64-latest+amdsev.args} | 7 +- ...nual-efi-sev-snp.x86_64-latest+amdsev.xml} | 12 +- .../firmware-manual-efi-sev-snp.xml | 21 + ...anual-efi-tdx.x86_64-latest+inteltdx.args} | 9 +- ...manual-efi-tdx.x86_64-latest+inteltdx.xml} | 11 +- .../firmware-manual-efi-tdx.xml | 25 ++ tests/qemuxmlconftest.c | 19 + 49 files changed, 571 insertions(+), 263 deletions(-) create mode 100644 tests/qemuxmlconfdata/firmware-auto-bios-rw.x86_64-latest.err copy tests/qemuxmlconfdata/{firmware-manual-efi-nvram-template-nonstandard.x86_64-latest.xml => firmware-auto-bios-rw.x86_64-latest.xml} (83%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-bios-rw.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-loader-qcow2-rom.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-loader-qcow2-rom.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-mismatch-nvramtemplate.x86_64-latest.err copy tests/qemuxmlconfdata/{firmware-manual-efi-nvram-template-nonstandard.x86_64-latest.xml => firmware-auto-efi-format-mismatch-nvramtemplate.x86_64-latest.xml} (83%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-mismatch-nvramtemplate.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvram-raw-loader-path.x86_64-latest.args} (90%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvram-raw-loader-path.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvram-raw-loader-path.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvram-raw-nvramtemplate-path.x86_64-latest.args} (90%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvram-raw-nvramtemplate-path.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvram-raw-nvramtemplate-path.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvram-raw.x86_64-latest.abi-update.args} (100%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvram-raw.x86_64-latest.abi-update.xml} (100%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvram-raw.x86_64-latest.args} (100%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvram-raw.x86_64-latest.xml} (100%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvram-raw.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvramtemplate-qcow2.x86_64-latest.args} (77%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvramtemplate-qcow2.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvramtemplate-qcow2.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-bios-rw.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-manual-bios-rw.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-manual-efi-nvram-template-nonstandard-format.x86_64-latest.args} (70%) copy tests/qemuxmlconfdata/{firmware-manual-efi-nvram-template-nonstandard.x86_64-latest.xml => firmware-manual-efi-nvram-template-nonstandard-format.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-nvram-template-nonstandard-format.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-manual-efi-nvram-template-nonstandard-legacy-paths.x86_64-latest.args} (89%) copy tests/qemuxmlconfdata/{firmware-manual-efi-loader-path-nonstandard.x86_64-latest.xml => firmware-manual-efi-nvram-template-nonstandard-legacy-paths.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-nvram-template-nonstandard-legacy-paths.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-rw-nvram.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-rw-nvram.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-manual-efi-sev-snp.x86_64-latest+amdsev.args} (74%) copy tests/qemuxmlconfdata/{firmware-manual-efi-nvram-template-nonstandard.x86_64-latest.xml => firmware-manual-efi-sev-snp.x86_64-latest+amdsev.xml} (75%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-sev-snp.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-manual-efi-tdx.x86_64-latest+inteltdx.args} (59%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-manual-efi-tdx.x86_64-latest+inteltdx.xml} (69%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-tdx.xml -- 2.52.0

3 38

[PATCH v2 0/5] cover: RFE libvirt secret encryption on disk
by Arun Menon 06 Jan '26

06 Jan '26

Libvirt secrets are stored unencrypted on the disk. With this series we want to start encrypting the secrets. 1. Introduce the GnuTLS decryption wrapper functions that work exact opposite to the encryption wrappers. 2. Add a new service called virt-secrets-init-encryption, that is linked to the virtsecretd and libvirtd service. virtsecretd and libvirtd services only starts after the new service generates a random encryption key. 3. Add a new secret.conf configuration file that helps user to set a. secrets_encryption_key - allows the user to specify the encryption key file path, in case the default key is not to be used. b. encrypt_data - set to 0 or 1. If set to 1, then the newly added secrets will be encrypted. 4. Rename the file name attribute in virSecretObj structure to secretValueFile. 5. Once we have the encryption key, and a reliable way to tell the daemon what encryption scheme the secret object is using, we can encrypt the secrets on disk and store them in <uuid>.<encryption_scheme> format. It is important to note that if the encryption key is changed between restarts, then the respective secret will not be loaded by the driver. This is a sincere attempt to improve upon the already submitted patch https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KE6G… Resolves: https://issues.redhat.com/browse/RHEL-7125 --- Changes in v2: - Fixed a regression in the decryption logic. ciphertext length was incorrectly calculated. - Removed virSecretEncryptionScheme enum. It is no longer required. All the changes will be done at one place i.e. schemeInfo array. In future we can append to the array, when we want to add new cipher modes. - Add Requires= and After= directives in libvirtd service. Remove unnecessary configuration settings from src/secret meson.build. - Other minor refactoring and header include fix. Arun Menon (5): util: Add support for GnuTLS decryption secret: Set up default encryption secret key for the virtsecretd service secret: Add secret.conf configuration file and parse it secret: Rename virSecretObj structure attribute from base64File to secretValueFile secret: Add functionality to load and save secrets in encrypted format include/libvirt/virterror.h | 1 + libvirt.spec.in | 7 + po/POTFILES | 1 + src/conf/virsecretobj.c | 183 ++++++++++++++---- src/conf/virsecretobj.h | 18 +- src/libvirt_private.syms | 1 + src/meson.build | 1 + src/remote/libvirtd.service.in | 4 + src/secret/libvirt_secrets.aug | 40 ++++ src/secret/meson.build | 31 +++ src/secret/secret.conf.in | 14 ++ src/secret/secret_config.c | 179 +++++++++++++++++ src/secret/secret_config.h | 40 ++++ src/secret/secret_driver.c | 34 +++- src/secret/test_libvirt_secrets.aug.in | 6 + .../virt-secret-init-encryption.service.in | 8 + src/secret/virtsecretd.service.extra.in | 8 + src/util/vircrypto.c | 126 +++++++++++- src/util/vircrypto.h | 8 + src/util/virerror.c | 3 + tests/vircryptotest.c | 65 +++++++ 21 files changed, 728 insertions(+), 50 deletions(-) create mode 100644 src/secret/libvirt_secrets.aug create mode 100644 src/secret/secret.conf.in create mode 100644 src/secret/secret_config.c create mode 100644 src/secret/secret_config.h create mode 100644 src/secret/test_libvirt_secrets.aug.in create mode 100644 src/secret/virt-secret-init-encryption.service.in -- 2.51.1

2 8

[RFC 00/10] qom: Support marking object properties as deprecated
by Zhao Liu 06 Jan '26

06 Jan '26

Hi, This RFC is the follow-up work of v2.6 & v2.7 machines' removal [*], and tries to introduce a general way to provide deprecation hint for external user. Its core idea is to detect external property settings (as well as specific internal property settings, such as the compat property). I think deprecated properties and internal-only properties are quite similar, as both require consideration of external property usage. But the former only triggers a warning, while the latter stops all external access attempts. For simplicity, this RFC series only considers deprecated properties. Brief Introduction ================== Now the common (but a bit fragmented) way to mark a property deprecated is to add the warning in its accssors, or just document the deprecation in docs/about/deprecated.rst without any hint when someone touches that property. Ideally, it's better to provide some hints to external user when he tries to set the property via command line or HMP. But this is pretty inconvenient (even impossible) for such qdev properties, which are defined via DEFINE_PROP_* macros in the Property array. For qdev properties, their accessors are provided by pre-defined PropertyInfo, so that it's possible to modify PropertyInfo for a single "deprecated" property. Then it's necessary to introduce property flags to mark some properties as deprecated, and to check the property flags when set the property, thereby to print a deprecation warning. This not only benefits traditional qdev properties but also helps the deprecation of generic objects. Note, internal attempt (except the compat case) should not trigger the deprecation warning but external user should see the deprecation information. I think the most complex part is identifying the paths for property settings (both external command-line options and internal specific configurations). This series currently covers the following scenarios (which I consider to be particularly important): External cases: 1) External global properties: * -global command line option. * -cpu command line features. * suger properties from object_compat_props[2] 2) External ("TYPE_USER_CREATABLE") object: * -object command line used for external ("TYPE_USER_CREATABLE") object. 3) External device: * -device command line - parsed based on keyval or json. 4) External machine options: * -machine command line - parsed based on keyval. 5) External accelerator options: * -accel command line. 6) HMP command: * "qom-set" command. Internal cases: 1) internal global properties: * compat properties from object_compat_props[0,1]. 2) Internal machine options: * Builtin default machine options string: MachineClass::default_machine_opts - parsed based on keyval, too. In fact, there are still some special device command lines that haven't been considered yet. But I believe the remaining cases can be gradually expanded? If this approach is feasible, it's possible to further introduce an "internal" flag to prevent external access to compat property. [*]: hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines https://lore.kernel.org/qemu-devel/20251202162835.3227894-1-zhao1.liu@intel… Thanks and Best Regards, Zhao --- Zhao Liu (10): qom: Rename ObjectPropertyFlags to ObjectPropertyAccessorFlags qom: Add basic object property deprecation hint support qom: Check property deprecation flag for global property qom: Check property deprecation flag for properities from qdict system/vl: Check property deprecation flag for properities of accelerator qom/qom-hmp-cmd: Check property deprecation flag for "qom-set" command hw/core/qdev-properties: Allow to mark qdev property as deprecated target/i386: Deprecate fill-mtrr-mask property target/i386: Deprecate cpuid-0xb property hw/intc/ioapic: Deprecate version property docs/about/deprecated.rst | 31 +++++++++ hw/core/qdev-properties.c | 24 +++---- hw/intc/ioapic.c | 3 +- include/hw/qdev-properties.h | 18 ++++++ include/qom/object.h | 120 +++++++++++++++++++++++++++++++---- qom/object.c | 101 ++++++++++++++++++++++------- qom/object_interfaces.c | 2 +- qom/qom-hmp-cmds.c | 2 +- system/vl.c | 2 +- target/i386/cpu.c | 4 +- 10 files changed, 253 insertions(+), 54 deletions(-) -- 2.34.1

2 18

[PATCH v3 0/7] qemu: Implement support for iommufd
by Nathan Chen 05 Jan '26

05 Jan '26

From: Nathan Chen <nathanc(a)nvidia.com> Hi, This is a follow up to the second patch series [0] for using iommufd to propagate DMA mappings to the kernel for VM-assigned host devices in a qemu VM. We add a new 'iommufd' attribute for hostdev devices to be associated with the iommufd object. For instance, specifying the iommufd object and associated hostdev in a VM definition: <devices> ... <hostdev mode='subsystem' type='pci' managed='no'> <driver iommufd='yes'/> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='no'> <driver iommufd='yes'/> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> ... </devices> This would get translated to a qemu command line with the arguments below. Note that libvirt will open the /dev/iommu and VFIO cdev, passing the associated fd number to qemu: -object '{"qom-type":"iommufd","id":"iommufd0","fd":"24"}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","iommufd":"iommufd0","fd":"22","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","iommufd":"iommufd0","fd":"25","bus":"pci.22","addr":"0x0"}' \ Changes from v2: - Set per-process memory accounting mode for iommufd - Separated out formatting of iommufd object from qemuBuildHostdevCommandLine - Placed hostdev private data implementation in a separate commit - Allocate hostdev private data unconditionally - Compare FDs against -1 - Integrated callback function in virQEMUDriverPrivateDataCallbacks for qemuDomainHostdevPrivateNew - Dropped qemuProcessCloseVfioFds - Addressed other feedback from v2 (formatting, includes, etc.) - Revised seclabel logic to be device-specific for AppArmor and to allow paths for SELinux/DAC Thanks to Ján Tomko for sharing some of the above changes in a personal repo. I have included changes directly from that repo and added Suggested-by or Signed-off-by tags on various commits containing the changes. This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/iommufd-12-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KFYU… Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (7): qemu: Implement support for associating iommufd to hostdev qemu: Introduce privateData for hostdevs qemu: open VFIO FDs from libvirt backend qemu: open iommufd FD from libvirt backend qemu: Set per-process memory accounting for iommufd qemu: Update Cgroup, namespace, and seclabel for iommufd tests: qemuxmlconfdata: provide iommufd sample XML and CLI args cover letter: qemu: Implement support for iommufd docs/formatdomain.rst | 7 + po/POTFILES | 1 + src/bhyve/bhyve_parse_command.c | 2 +- src/conf/device_conf.c | 11 ++ src/conf/device_conf.h | 1 + src/conf/domain_conf.c | 13 +- src/conf/domain_conf.h | 5 +- src/conf/schemas/basictypes.rng | 5 + src/libvirt_private.syms | 4 + src/libxl/xen_common.c | 2 +- src/libxl/xen_xl.c | 2 +- src/lxc/lxc_native.c | 2 +- src/qemu/qemu_cgroup.c | 26 ++-- src/qemu/qemu_command.c | 74 ++++++++++ src/qemu/qemu_domain.c | 41 ++++++ src/qemu/qemu_domain.h | 20 +++ src/qemu/qemu_namespace.c | 16 ++- src/qemu/qemu_process.c | 126 ++++++++++++++++++ src/security/security_apparmor.c | 33 ++++- src/security/security_dac.c | 60 +++++++-- src/security/security_selinux.c | 58 ++++++-- src/security/virt-aa-helper.c | 32 ++++- src/util/meson.build | 1 + src/util/viriommufd.c | 89 +++++++++++++ src/util/viriommufd.h | 23 ++++ src/util/virpci.c | 69 ++++++++++ src/util/virpci.h | 2 + src/vbox/vbox_common.c | 2 +- .../iommufd-q35.x86_64-latest.args | 41 ++++++ .../iommufd-q35.x86_64-latest.xml | 60 +++++++++ tests/qemuxmlconfdata/iommufd-q35.xml | 38 ++++++ .../iommufd-virt.aarch64-latest.args | 33 +++++ .../iommufd-virt.aarch64-latest.xml | 34 +++++ tests/qemuxmlconfdata/iommufd-virt.xml | 22 +++ .../iommufd.x86_64-latest.args | 35 +++++ .../qemuxmlconfdata/iommufd.x86_64-latest.xml | 38 ++++++ tests/qemuxmlconfdata/iommufd.xml | 30 +++++ tests/qemuxmlconftest.c | 33 +++++ tests/virhostdevtest.c | 2 +- 39 files changed, 1031 insertions(+), 62 deletions(-) create mode 100644 src/util/viriommufd.c create mode 100644 src/util/viriommufd.h create mode 100644 tests/qemuxmlconfdata/iommufd-q35.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd-q35.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd-q35.xml create mode 100644 tests/qemuxmlconfdata/iommufd-virt.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd-virt.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd-virt.xml create mode 100644 tests/qemuxmlconfdata/iommufd.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd.xml -- 2.43.0

3 19