November 2025 - Devel - libvirt List Archives

[PULL 00/32] Next pr patches
by Daniel P. Berrangé 23 Apr '26

23 Apr '26

The following changes since commit 53b41bb78950912ba2d9809eef6b45e4df30c647: Merge tag 'pull-target-arm-20251031' of https://gitlab.com/pm215/qemu into staging (2025-11-01 10:52:48 +0100) are available in the Git repository at: https://gitlab.com/berrange/qemu tags/next-pr-pull-request for you to fetch changes up to 2aaca8c6d22b18786ceff51189704113d0639590: docs: creation of x509 certs compliant with post-quantum crypto (2025-11-03 10:45:55 +0000) ---------------------------------------------------------------- Merge crypto and other misc fixes / features * Increase minimum gnutls to 3.7.5 * Increase minimum libgcrypt to 1.9.4 * Increase minimum nettle to 3.7.3 * Drop obsolete in-tree XTS impl * Fix memory leak when loading certificates * Remove/reduce duplication when loading certifcates * Fix possible crash when certificates are unloaded while an active TLS connection is using when in a TLS handshake operation * Deprecate use of dh-params.pem file * Document how to create certificates with Post-Quantum Cryptography compliant algorithms. * Support loading multiple certificate identities to allow support for Post-Quantum crypto in parallel with traditional RSA/ECC * Add "-run-with exit-with-parent=on" parameter * Flush pending errors when seeing ENOBUFS with a zero-copy send attempt * Fix data buffer parameters in hash & IO channel APIs to use 'void *' ---------------------------------------------------------------- Daniel P. Berrangé (26): crypto: bump min gnutls to 3.7.5 crypto: unconditionally enable gnutls XTS support crypto: bump min libgcrypt to 1.9.4 crypto: bump min nettle to 3.7.3 crypto: drop in-tree XTS cipher mode impl crypto: remove redundant parameter checking CA certs crypto: add missing free of certs array crypto: replace stat() with access() for credential checks crypto: remove redundant access() checks before loading certs crypto: move check for TLS creds 'dir' property crypto: use g_autofree when loading x509 credentials crypto: remove needless indirection via parent_obj field crypto: move release of DH parameters into TLS creds parent crypto: shorten the endpoint == server check in TLS creds crypto: remove duplication loading x509 CA cert crypto: reduce duplication in handling TLS priority strings crypto: introduce method for reloading TLS creds crypto: introduce a wrapper around gnutls credentials crypto: fix lifecycle handling of gnutls credentials objects crypto: make TLS credentials structs private crypto: deprecate use of external dh-params.pem file crypto: avoid loading the CA certs twice crypto: avoid loading the identity certs twice crypto: expand logic to cope with multiple certificate identities crypto: support upto 5 parallel certificate identities docs: creation of x509 certs compliant with post-quantum crypto Manish Mishra (1): io: flush zerocopy socket error queue on sendmsg failure due to ENOBUF Philippe Mathieu-Daudé (2): crypto/hash: Have hashing functions take void * buffer argument io/channel: Have read/write functions take void * buffer argument Richard W.M. Jones (2): Implement -run-with exit-with-parent=on tests/qtest: Use exit-with-parent=on in qtest invocations Tejus GK (1): io: add a "blocking" field to QIOChannelSocket crypto/cipher-gnutls.c.inc | 8 - crypto/cipher-nettle.c.inc | 44 -- crypto/cipher.c | 2 +- crypto/hash.c | 16 +- crypto/hmac.c | 8 +- crypto/meson.build | 10 +- crypto/tlscreds.c | 79 ++-- crypto/tlscredsanon.c | 64 +-- crypto/tlscredsbox.c | 101 +++++ crypto/tlscredsbox.h | 50 +++ crypto/tlscredspriv.h | 36 +- crypto/tlscredspsk.c | 64 ++- crypto/tlscredsx509.c | 593 +++++++++++++++++--------- crypto/tlssession.c | 139 ++---- crypto/trace-events | 1 + crypto/xts.c | 250 ----------- docs/about/deprecated.rst | 9 + docs/system/tls.rst | 134 +++++- include/crypto/hash.h | 8 +- include/crypto/hmac.h | 4 +- include/crypto/tlscreds.h | 26 ++ include/crypto/tlscredsx509.h | 6 + include/crypto/tlssession.h | 4 +- include/crypto/xts.h | 82 ---- include/io/channel-socket.h | 6 + include/io/channel.h | 14 +- include/qemu/exit-with-parent.h | 57 +++ io/channel-socket.c | 86 +++- io/channel-tls.c | 4 +- io/channel.c | 14 +- meson.build | 69 +-- qemu-options.hx | 13 +- system/exit-with-parent.c | 140 ++++++ system/meson.build | 1 + system/vl.c | 13 + tests/qtest/libqtest.c | 22 +- tests/unit/meson.build | 3 - tests/unit/test-crypto-block.c | 3 +- tests/unit/test-crypto-tlscredsx509.c | 8 +- tests/unit/test-crypto-tlssession.c | 4 +- tests/unit/test-crypto-xts.c | 529 ----------------------- ui/vnc.c | 9 +- 42 files changed, 1208 insertions(+), 1525 deletions(-) create mode 100644 crypto/tlscredsbox.c create mode 100644 crypto/tlscredsbox.h delete mode 100644 crypto/xts.c delete mode 100644 include/crypto/xts.h create mode 100644 include/qemu/exit-with-parent.h create mode 100644 system/exit-with-parent.c delete mode 100644 tests/unit/test-crypto-xts.c -- 2.51.1

3 36

Re: Clarification Needed: virsh snapshot-delete Behavior with External Snapshots (--disk-only)
by Peter Krempa 10 Apr '26

10 Apr '26

On Wed, Jul 23, 2025 at 04:57:57 +0000, P, Rajasekar via Users wrote: > Hello libvirt community, > > I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option). > > **Environment:** > - libvirt version: 10.5.0 Note that this was released almost a year ago. > - Kernel version: 5.14.0-503.22.1.el9_5.x86_64 > - Disk image format: qcow2 > - Host OS: RHEL 9.5 > > **Steps to reproduce:** > 1. Create an external snapshot: > virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic > 2. Delete the snapshot: > virsh snapshot-delete <vm> --snapshotname snap1 > > **Observed behavior:** > - Changes from the overlay (snapshot) file are merged into the base image. > - The snapshot metadata is removed from libvirt. > - The snapshot file remains on disk (appears orphaned). You mean that the original overlay images remained on disk? e.g. /path/to/originalimage.snap1 ? > **Questions:** > - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step. Yes it is intended, because deleting a snapshot is effectively meaning "I don't want to return to this point any more" so the extra overlay makes no sense. > - Should the snapshot file be deleted automatically, or is manual cleanup required? If you mean the overlay, then yes it should have been deleted. > - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots? The semantics of external and internal snapshots are supposed to be indentical. I don't think we document to a deep extent the actual behaviour WRT to the disk files.

2 1

[PATCH v2] virhostcpu: Fix potential use of unallocated memory
by Felix Huettner 26 Mar '26

26 Mar '26

In case of a host that has a large number of cpus offline the count of host cpus and the last bit set in the virHostCPUGetOnlineBitmap might diverge significantly. This can e.g. be the case when disabling smt via /sys/devices/system/cpu/smt/control. On the host this looks like: ``` $ cat /sys/devices/system/cpu/present 0-255 $ cat /sys/devices/system/cpu/online 0-127 ``` However in this case virBitmapToData previously only allocated 16 bytes for the output bitmap. This is becase the last set bit is on the 15th byte. Users of virHostCPUGetMap however rely on the "cpumap" containing enough space for all existing cpus (so they would expect 32 bytes in this case). E.g. cmdNodeCpuMap relies on this for its output. It will then actually read 32 bytes from the start of the "cpumap" address where in this case the last 16 of these bytes are uninitialized. This manifests itself in flapping outputs of "virsh nodecpumap --pretty" like: ``` $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,202 $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,197 $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,196-197 ``` This in turn potentially causes users of this data to report wrong cpu counts. Note that this only seems to happen with at least 256 physical cpus where at least 128 are offline. We fix this by preallocating the expected bitmap size. Signed-off-by: Felix Huettner <felix.huettner(a)stackit.cloud> --- src/util/virhostcpu.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index 5dbcc8987c..4805484b1d 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -1090,28 +1090,26 @@ virHostCPUGetMap(unsigned char **cpumap, unsigned int flags) { g_autoptr(virBitmap) cpus = NULL; - int ret = -1; - int dummy; + int ncpus = virHostCPUGetCount(); virCheckFlags(0, -1); if (!cpumap && !online) - return virHostCPUGetCount(); + return ncpus; if (!(cpus = virHostCPUGetOnlineBitmap())) - goto cleanup; + return -1; + + if (cpumap) { + int len = (ncpus + CHAR_BIT) / CHAR_BIT; + *cpumap = g_new0(unsigned char, len); + virBitmapToDataBuf(cpus, *cpumap, len); + } - if (cpumap) - virBitmapToData(cpus, cpumap, &dummy); if (online) *online = virBitmapCountBits(cpus); - ret = virHostCPUGetCount(); - - cleanup: - if (ret < 0 && cpumap) - VIR_FREE(*cpumap); - return ret; + return ncpus; } base-commit: c5a73f75bc6cae4f466d0a6344d5b3277ac9c2f4 -- 2.43.0

2 1

[PULL 02/18] deprecation: don't enable TCG plugins by default with TCI
by Alex Bennée 28 Feb '26

28 Feb '26

The softmmu memory instrumentation test sees so many more accesses than a normal translated host and its really not worth fixing up. Lets deprecate this odd configuration and save on the CI cycles. Reviewed-by: Pierrick Bouvier <pierrick.bouvier(a)linaro.org> Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> Message-Id: <20240916085400.1046925-3-alex.bennee(a)linaro.org> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 809b2b9b81..c0aa52def5 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -196,6 +196,14 @@ benefits from having plenty of host memory it seems reasonable to encourage users to use 64 bit builds of QEMU for analysis work whatever targets they are instrumenting. +TCG Plugin support not enabled by default with TCI (since 9.2) +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +While the TCG interpreter can interpret the TCG ops used by plugins it +is going to be so much slower it wouldn't make sense for any serious +instrumentation. Due to implementation differences there will also be +anomalies in things like memory instrumentation. + System emulator CPUs -------------------- diff --git a/configure b/configure index cc8e1ed5b8..aa7aae70fa 100755 --- a/configure +++ b/configure @@ -629,6 +629,9 @@ meson_option_parse() { exit 1 fi } +has_meson_option() { + test "${meson_options#*"$1"}" != "$meson_options" +} meson_add_machine_file() { if test "$cross_compile" = "yes"; then @@ -1048,8 +1051,12 @@ if test "$static" = "yes" ; then plugins="no" fi if test "$plugins" != "no" && test $host_bits -eq 64; then - plugins=yes - subdirs="$subdirs contrib/plugins" + if has_meson_option "-Dtcg_interpreter=true"; then + plugins="no" + else + plugins=yes + subdirs="$subdirs contrib/plugins" + fi fi cat > $TMPC << EOF -- 2.39.5

2 1

[PATCH v2 0/2] allow migrations with the ext transport
by Sergey Dyasli 19 Feb '26

19 Feb '26

Hello, I have a use case for live-migration where the socket of the destination libvirtd is proxied by an mTLS WebSocket proxy. Since there is no WebSocket support in Libvirt, I've decided to use the existing ext transport and point it to a proxy binary on the source host of live-migration. While doing that, I've discovered a couple of roadblocks: 1. There is no way of passing cmdline arguments to the ext program 2. Live-migrations using ext transport fail localhost checks This short series addresses those limitations. Sergey Dyasli (2): remote: allow passing argv to the ext transport remote: allow migrations with the ext transport v1 -> v2: - new way of passing argv src/libvirt-domain.c | 8 +++++--- src/remote/remote_driver.c | 30 ++++++++++++++++++++++++++---- src/util/viruri.c | 32 ++++++++++++++++++++++++++++++++ src/util/viruri.h | 2 ++ 4 files changed, 65 insertions(+), 7 deletions(-) -- 2.43.7

3 5

[PATCH v6] qapi: net: deprecate vhostforce option
by Vladimir Sementsov-Ogievskiy 18 Feb '26

18 Feb '26

This option for tap and vhost-user netdevs doesn't make sense since long ago (10 years!), starting from commits: 1e7398a140f7a6 ("vhost: enable vhost without without MSI-X") 24f938a682d934 ("vhost user:support vhost user nic for non msi guests") Prior these commits, to enable kernel vhost-net, or vhost-user-net for some specific kind of guests (that don't have MSI-X support), you should have set vhostforce=on. Now guest type doesn't matter, all guests are equal for these options logic. For tap the current logic is: vhost=on / vhost=off : vhostforce ignored, doesn't make sense vhost unset : vhostforce counts, enabling vhost So you may enable vhost for tap several ways: - vhost=on - vhostforce=on - vhost=on + vhostforce=on - and even vhost=on + vhostforce=off - they are all equal. For vhost-user we simply ignore the vhostforce option at all in the code. Let's finally deprecate the extra options. Also, fix @vhostforce documentation everywhere to show the real picture, and update vhost-user test to not use deprecated option. While updating command line options, drop "experimental" word from "experimental in kernel accelerator". vhost-net is in production for years. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov(a)yandex-team.ru> Reviewed-by: Markus Armbruster <armbru(a)redhat.com> --- v6: - update numbers 10.2 -> 11.0 - add r-b by Markus docs/about/deprecated.rst | 11 +++++++++++ qapi/net.json | 18 ++++++++++++++---- qemu-options.hx | 13 +++++-------- tests/qtest/vhost-user-test.c | 2 +- 4 files changed, 31 insertions(+), 13 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 03e29915f0..3f97392a45 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -498,6 +498,17 @@ Backend ``memory`` (since 9.0) ``memory`` is a deprecated synonym for ``ringbuf``. +TAP ``vhostforce`` (since 11.0) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``vhostforce`` option is redundant with the ``vhost`` option. +If they conflict, ``vhost`` takes precedence. Just use ``vhost``. + +Vhost-user ``vhostforce`` (since 11.0) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``vhostforce`` option is a no-op. Do not use it. + CPU device properties ''''''''''''''''''''' diff --git a/qapi/net.json b/qapi/net.json index 118bd34965..9a00d578e9 100644 --- a/qapi/net.json +++ b/qapi/net.json @@ -348,13 +348,18 @@ # @vhostfds: file descriptors of multiple already opened vhost net # devices # -# @vhostforce: vhost on for non-MSIX virtio guests +# @vhostforce: enable vhost-net network accelerator. Ignored when +# @vhost is set. # # @queues: number of queues to be created for multiqueue capable tap # # @poll-us: maximum number of microseconds that could be spent on busy # polling for tap (since 2.7) # +# Features: +# +# @deprecated: Member @vhostforce is deprecated. Use @vhost instead. +# # Since: 1.2 ## { 'struct': 'NetdevTapOptions', @@ -371,7 +376,7 @@ '*vhost': 'bool', '*vhostfd': 'str', '*vhostfds': 'str', - '*vhostforce': 'bool', + '*vhostforce': { 'type': 'bool', 'features': [ 'deprecated' ] }, '*queues': 'uint32', '*poll-us': 'uint32'} } @@ -610,17 +615,22 @@ # # @chardev: name of a unix socket chardev # -# @vhostforce: vhost on for non-MSIX virtio guests (default: false). +# @vhostforce: silently ignored, exists just for backward +# compatibility. # # @queues: number of queues to be created for multiqueue vhost-user # (default: 1) (Since 2.5) # +# Features: +# +# @deprecated: Member @vhostforce is deprecated. +# # Since: 2.1 ## { 'struct': 'NetdevVhostUserOptions', 'data': { 'chardev': 'str', - '*vhostforce': 'bool', + '*vhostforce': { 'type': 'bool', 'features': [ 'deprecated' ] }, '*queues': 'int' } } ## diff --git a/qemu-options.hx b/qemu-options.hx index fca2b7bc74..414b762743 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -2882,7 +2882,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, #else "-netdev tap,id=str[,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile]\n" " [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n" - " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n]\n" + " [,vhostfd=h][,vhostfds=x:y:...:z][,queues=n]\n" " [,poll-us=n]\n" " configure a host TAP network backend with ID 'str'\n" " connected to a bridge (default=" DEFAULT_BRIDGE_INTERFACE ")\n" @@ -2898,9 +2898,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, " default is disabled 'sndbuf=0' to enable flow control set 'sndbuf=1048576')\n" " use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap flag\n" " use vnet_hdr=on to make the lack of IFF_VNET_HDR support an error condition\n" - " use vhost=on to enable experimental in kernel accelerator\n" - " (only has effect for virtio guests which use MSIX)\n" - " use vhostforce=on to force vhost on for non-MSIX virtio guests\n" + " use vhost=on to enable in kernel accelerator\n" " use 'vhostfd=h' to connect to an already opened vhost net device\n" " use 'vhostfds=x:y:...:z to connect to multiple already opened vhost net devices\n" " use 'queues=n' to specify the number of queues to be created for multiqueue TAP\n" @@ -2991,7 +2989,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, " use 'start-queue=m' to specify the first queue that should be used\n" #endif #ifdef CONFIG_POSIX - "-netdev vhost-user,id=str,chardev=dev[,vhostforce=on|off]\n" + "-netdev vhost-user,id=str,chardev=dev\n" " configure a vhost-user network, backed by a chardev 'dev'\n" #endif #ifdef __linux__ @@ -3882,12 +3880,11 @@ SRST for insertion into the socket map. The combination of 'map-path' and 'sock-fds' together is not supported. -``-netdev vhost-user,chardev=id[,vhostforce=on|off][,queues=n]`` +``-netdev vhost-user,chardev=id[,queues=n]`` Establish a vhost-user netdev, backed by a chardev id. The chardev should be a unix domain socket backed one. The vhost-user uses a specifically defined protocol to pass vhost ioctl replacement - messages to an application on the other end of the socket. On - non-MSIX guests, the feature can be forced with vhostforce. Use + messages to an application on the other end of the socket. Use 'queues=n' to specify the number of queues to be created for multiqueue vhost-user. diff --git a/tests/qtest/vhost-user-test.c b/tests/qtest/vhost-user-test.c index d2bb21d5b9..f977f50baf 100644 --- a/tests/qtest/vhost-user-test.c +++ b/tests/qtest/vhost-user-test.c @@ -46,7 +46,7 @@ #define QEMU_CMD_SHM " -m %d -object memory-backend-shm,id=mem,size=%dM," \ " -numa node,memdev=mem" #define QEMU_CMD_CHR " -chardev socket,id=%s,path=%s%s" -#define QEMU_CMD_NETDEV " -netdev vhost-user,id=hs0,chardev=%s,vhostforce=on" +#define QEMU_CMD_NETDEV " -netdev vhost-user,id=hs0,chardev=%s" #define HUGETLBFS_MAGIC 0x958458f6 -- 2.48.1

2 4

[PATCH v3 0/7] USB hostdev: allow addressing by port
by Maximilian Martin 11 Feb '26

11 Feb '26

Currently, only vendor/product and bus/device matching are supported for USB host devices. Neither of these provide a stable and persistent way of assigning a guest a specific host device. Vendor/product can be ambiguous. Device numbers change on every enumeration. This patch adds a bus/port matching, which allows a specific port on the host to be specified using the dotted notation found in Linux's "devpath" sysfs attribute. The path series is based on the previous work of Thomas Hebb: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7U3… This resubmission includes Daniel's patch which extends the USB hostdev test logic. Maximilian Martin (7): tests: validate an XML config with USB vendor/product set virusb test data: add devpath files for port addressing domain_conf, virhostdev, virusb, virusb test: add bus/port matching schema: add USB port attribute tests: validate an XML config with USB bus/port set nodedev: add USB port to nodedev XML docs: add description for USB port matching docs/formatdomain.rst | 29 ++-- src/conf/domain_conf.c | 58 ++++++- src/conf/domain_conf.h | 1 + src/conf/node_device_conf.c | 5 + src/conf/node_device_conf.h | 1 + src/conf/schemas/basictypes.rng | 31 ++++ src/conf/schemas/domaincommon.rng | 41 +---- src/conf/schemas/nodedev.rng | 3 + src/hypervisor/virhostdev.c | 131 ++++++++------ src/libvirt_private.syms | 2 - src/node_device/node_device_udev.c | 4 + src/util/virusb.c | 160 ++++++------------ src/util/virusb.h | 22 +-- .../usb_device_1d6b_1_0000_00_1d_0.xml | 1 + ...ostdev-usb-address-port.x86_64-latest.args | 36 ++++ ...hostdev-usb-address-port.x86_64-latest.xml | 45 +++++ .../hostdev-usb-address-port.xml | 28 +++ ...tdev-usb-vendor-product.x86_64-latest.args | 35 ++++ ...stdev-usb-vendor-product.x86_64-latest.xml | 44 +++++ .../hostdev-usb-vendor-product.xml | 36 ++++ tests/qemuxmlconftest.c | 25 +++ tests/virusbtest.c | 149 +++++++++++----- .../sys_bus_usb/devices/1-1.5.3.1/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.4/devpath | 1 + .../sys_bus_usb/devices/1-1.5.5/devpath | 1 + .../sys_bus_usb/devices/1-1.5.6/devpath | 1 + .../sys_bus_usb/devices/1-1.5/devpath | 1 + .../sys_bus_usb/devices/1-1.6/devpath | 1 + .../sys_bus_usb/devices/1-1/devpath | 1 + .../sys_bus_usb/devices/2-1.2/devpath | 1 + .../sys_bus_usb/devices/2-1/devpath | 1 + .../sys_bus_usb/devices/usb1/devpath | 1 + .../sys_bus_usb/devices/usb2/devpath | 1 + .../sys_bus_usb/devices/usb3/devpath | 1 + .../sys_bus_usb/devices/usb4/devpath | 1 + 37 files changed, 631 insertions(+), 271 deletions(-) create mode 100644 tests/qemuxmlconfdata/hostdev-usb-address-port.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/hostdev-usb-address-port.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/hostdev-usb-address-port.xml create mode 100644 tests/qemuxmlconfdata/hostdev-usb-vendor-product.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/hostdev-usb-vendor-product.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/hostdev-usb-vendor-product.xml create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.4/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1.2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb4/devpath -- 2.39.5

3 13

Qemu pause-before-switchover and libvirt live migration
by Rogério Vinhal Nunes 02 Feb '26

02 Feb '26

Hello, I’m looking into the libvirt hooks that are available to make use of during a live migration, but there's only hooks on migration begin and migration end. On qemu directly I’m able to use pause-before-switchover migration capability to run a custom operation just before it moves to the destination, but within libvirt it seems that while this is leveraged internally, it’s not currently exposed to the client in a way I can use. Does anyone have any suggestions on how I could expose this to the client in a generic and sensible way? Thanks, Rogerio

3 11

[PATCH v2 0/1] x86: install modules-load.d file to load msr module
by Hector Cao 12 Jan '26

12 Jan '26

This submission is a follow-up (v2) of the discussion (RFC) that was happening at: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/ADJ4A... On x86, libvirt makes use of the API exposed by the msr kernel module to read the MSR (Model Specific Registers) values. On some Linux distros, this module is not loaded by default so libvirt might fail to read the MSR values and falls back to /dev/kvm to obtain these values. KVM might be behind in term of exposing all the values of the MSRs so using /dev/kvm is not ideal. This submission tries to make libvirt deploy the modules-load.d configuration so that linux loads the msr module at next boot. One caveat, libvirt installs only the file and does not trigger the load that is only done at next reboot, it is up to each distro to trigger immediately the load of the module without a reboot. v2: - only install the file when qemu driver is enabled Hector Cao (1): x86: install modules-load.d file to load msr module meson_options.txt | 1 + src/util/meson.build | 19 +++++++++++++++++++ src/util/modules-load.d/msr.conf | 1 + tools/virt-host-validate-qemu.c | 7 +++++++ 4 files changed, 28 insertions(+) create mode 100644 src/util/modules-load.d/msr.conf -- 2.45.2

3 8

[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 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 v1 0/4] Remove AST2700 A0
by Jamin Lin 30 Dec '25

30 Dec '25

v1: - Remove ast2700a0-evb machine - Remove ast2700-a0 SOC - Remove GIC 128 - 136 for AST2700 A0 *** BLURB HERE *** Jamin Lin (4): hw/arm: Remove ast2700a0-evb machine hw/arm/aspeed_ast27x0: Remove ast2700-a0 SOC hw/intc/aspeed: Remove GIC 128 - 136 docs/specs/aspeed-intc: Remove GIC 128 - 136 docs/about/deprecated.rst | 8 -- docs/specs/aspeed-intc.rst | 93 ++++---------- hw/arm/aspeed.c | 28 +--- hw/arm/aspeed_ast27x0.c | 121 ++---------------- hw/intc/aspeed_intc.c | 49 +------ .../functional/aarch64/test_aspeed_ast2700.py | 12 -- 6 files changed, 39 insertions(+), 272 deletions(-) -- 2.43.0

2 7

[Libvir] Hang with virt-install graphic=no on FC 6 6.93/F7 RC2
by libvirtuser 23 Dec '25

23 Dec '25

I had this problem and another user confirmed the same behavior on his machine: http://pastie.caboo.se/65417 Haven't tried it with *2925.10* yet. Also, is there a way to get more verbose info about what calls are causing the "configuration file syntax error" errors? Thanks. virt-install How large would you like the disk () to be (in gigabytes)? 4 ERROR: Must provide a file, not a directory for the disk What would you like to use as the disk (path)? /xen/images/x6.img Would you like to enable graphics support? (yes or no) no What is the install location? http://mirror.anl.gov/pub/fedora-linux-core/test/6.93/Fedora/i386/os/ Starting install... libvir: Xen Daemon error : GET operation failed: libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name Retrieving Fedora... 276 kB 00:01 Retrieving vmlinuz... 100% |=========================| 2.1 MB 00:16 Retrieving initrd.img... 100% |=========================| 5.4 MB 00:28 libvir: Xen Daemon error : GET operation failed: libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name Creating domain... 0 B 00:06 Linux version 2.6.20-2925.5.fc7xen (brewbuilder(a)ls20-bc1-14.build.redhat.com) (gcc version 4.1.2 20070317 (Red Hat 4.1.2-5)) #1 SMP Thu Mar 22 13:51:38 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize bail 0 copy_e820_map() start: 0000000000000000 size: 0000000020800000 end: 0000000020800000 type: 1 Xen: 0000000000000000 - 0000000020800000 (usable) 0MB HIGHMEM available. 520MB LOWMEM available. Using x86 segment limits to approximate NX protection Zone PFN ranges: DMA 0 -> 133120 Normal 133120 -> 133120 HighMem 133120 -> 133120 early_node_map[1] active PFN ranges 0: 0 -> 133120 ACPI in unprivileged domain disabled Built 1 zonelists. Total pages: 132080 Kernel command line: method=http://mirror.anl.gov/pub/fedora-linux-core/test/6.93/Fedora/i386/os/ Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c135f000 soft=c133f000 PID hash table entries: 4096 (order: 12, 16384 bytes) Xen reported: 1694.994 MHz processor. Console: colour dummy device 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS: 2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1064 kB per task-struct memory footprint: 1200 bytes Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: e1000000-f4ffe000, maxmem 2d7fe000 Memory: 503936k/532480k available (2030k kernel code, 19948k reserved, 1079k data, 180k init, 0k highmem) virtual kernel memory layout: fixmap : 0xf5315000 - 0xf57fe000 (5028 kB) pkmap : 0xf5000000 - 0xf5200000 (2048 kB) vmalloc : 0xe1000000 - 0xf4ffe000 ( 319 MB) lowmem : 0xc0000000 - 0xe0800000 ( 520 MB) .init : 0xc130e000 - 0xc133b000 ( 180 kB) .data : 0xc11fb9d9 - 0xc1309714 (1079 kB) .text : 0xc1000000 - 0xc11fb9d9 (2030 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4262.67 BogoMIPS (lpj=8525343) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 256K Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 11k freed Brought up 1 CPUs Grant table initialized NET: Registered protocol family 16 Brought up 1 CPUs PCI: Fatal: No config space access function found PCI: setting up Xen PCI frontend stub Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled xen_mem: Initialising balloon driver. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 9, 2097152 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered checking if image is initramfs... it is Freeing initrd memory: 7256k freed IA-32 Microcode Update Driver: v1.14-xen <tigran(a)veritas.com> audit: initializing netlink socket (disabled) audit(1180379657.981:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 BUG: at kernel/fork.c:994 copy_process() [<c1005d9a>] show_trace_log_lvl+0x1a/0x2f [<c1006343>] show_trace+0x12/0x14 [<c10063be>] dump_stack+0x16/0x18 [<c101d044>] copy_process+0x195/0x1245 [<c101e144>] do_fork+0x50/0x117 [<c1003351>] kernel_thread+0x8e/0x96 [<c102c701>] __call_usermodehelper+0x2d/0x46 [<c102cd4f>] run_workqueue+0x89/0x145 [<c102d711>] worker_thread+0xd5/0x102 [<c102ff27>] kthread+0xb3/0xdc [<c10058db>] kernel_thread_helper+0x7/0x10 ======================= rtc: IRQ 8 is not free. Non-volatile memory driver v1.2 Linux agpgart interface v0.101 (c) Dave Jones RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize input: Macintosh mouse button emulation as /class/input/input0 Xen virtual console successfully installed as xvc0 Event-channel device installed. usbcore: registered new interface driver libusual usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver PNP: No PS/2 controller found. Probing ports directly. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 Using IPI No-Shortcut mode XENBUS: Device with no driver: device/vbd/51712 XENBUS: Device with no driver: device/vif/0 Freeing unused kernel memory: 180k freed Write protecting the kernel read-only data: 762k ^[Domain installation still in progress. You can reconnect

2 1

[ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
by Vivek Kashyap 23 Dec '25

23 Dec '25

The VFIO PCI ABI has been extended to require userspace PF driver to set a VF token to a known value. The VF drivers are then required to provide this token to access the VF device. The vf-token is set by the PF driver before VF drivers can access the device. The kernel provides no means to retrieve the token in use; but there is no specification describing the distribution or level of confidentiality of the token. Qemu has been extended to require the vf-token when vf device is used. An important point to note is that the vf-token is required only when both the PF and VF are used in userspace. This patch series adds support to provide the vf-token (uuid format) in the domain XML and to generate the qemu commandline including the vf-token. To support vf-token the new element will be used as follows: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0' slot='0x00' function='0x1'> <vf-token uuid='00112233-4455-6677-8899-aabbccddeeff'/> </address> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </hostdev> The generated commandline will include the following: -device {"driver":"vfio-pci","host":"0000:00:0.1", "vf-token":"00112233-4455-6677-8899-aabbccddeeff", "id":"hostdev0","bus":"pci.0","addr":"0x1"} Changes since initial RFC based on review comments received: 1. Added documentation 2. Added test cases and ran successful test suite after each patch commit 3. fixed spaces, coding sytle, and uuid string format 4. Used S:vftoken in virJSONValueObjectAdd instead of a conditional Vivek Kashyap (8): Define the vf-token extension for PCI device Introduce the vf-token qemu capability This patch introduces the PCI address extension flag for vf-token This patch introduces new XML parser/formatter functions for parsing the vf-token Introduce a validation function for vf-token support in qemu and generate vf-token device attribute in qemu command line Provide information about the vf-token flag Add tests for the vf-token flag to the qemuxml2argv and qemuxml2xml test suites Update news about vf-token NEWS.rst | 8 +++ docs/formatdomain.rst | 3 ++ src/conf/device_conf.c | 49 ++++++++++++++++--- src/conf/domain_addr.h | 1 + src/conf/domain_conf.c | 8 +++ src/conf/schemas/basictypes.rng | 7 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 3 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 8 +++ src/qemu/qemu_domain_address.c | 3 ++ src/qemu/qemu_validate.c | 20 ++++++++ src/util/virpci.c | 7 +++ src/util/virpci.h | 10 ++++ .../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 1 + .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.xml | 1 + .../hostdev-vfio-vf-token.x86_64-latest.args | 34 +++++++++++++ .../hostdev-vfio-vf-token.xml | 22 +++++++++ tests/qemuxml2argvtest.c | 1 + .../hostdev-vfio-vf-token.x86_64-latest.xml | 40 +++++++++++++++ tests/qemuxml2xmltest.c | 1 + 22 files changed, 223 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml -- 2.33.8

3 19

[PATCH v2 0/5] qemu: Implement support for iommufd
by Nathan Chen 18 Dec '25

18 Dec '25

Hi, This is a follow up to the first 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"}' \ Note that when Libvirt launches the qemu process as an unprivileged user, i.e. libvirt-qemu, it is bound by the RLIMIT_MEMLOCK limit calculated based on how much RAM is assigned to the VM. IOMMUFD's unified memory accounting causes ENOMEM errors for large device BARs that exceed the process memlock limit. VFIO without IOMMUFD does not check device memory against the limit and therefore does not show this behavior. To work around the issue, we can specify CAP_IPC_LOCK=ep capability for the qemu binary to bypass the RLIMIT_MEMLOCK limit. I am working on a long-term fix in the kernel to mark device memory regions so they do not count against the RLIMIT_MEMLOCK limit for how much memory can be locked/pinned, as I/O device BARs do not consume host RAM. This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/iommufd-11-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/MYPM… Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (5): qemu: Implement support for associating iommufd to hostdev qemu: open VFIO FDs from libvirt backend qemu: open iommufd FD from libvirt backend qemu: Update Cgroup, namespace, and seclabel for iommufd tests: qemuxmlconfdata: provide iommufd sample XML and CLI args docs/formatdomain.rst | 8 + src/conf/device_conf.c | 12 ++ src/conf/device_conf.h | 1 + src/conf/domain_conf.h | 2 + src/conf/schemas/basictypes.rng | 5 + src/libvirt_private.syms | 1 + src/qemu/qemu_cgroup.c | 26 +-- src/qemu/qemu_command.c | 53 ++++- src/qemu/qemu_domain.c | 40 ++++ src/qemu/qemu_domain.h | 19 ++ src/qemu/qemu_namespace.c | 16 +- src/qemu/qemu_process.c | 186 ++++++++++++++++++ src/security/security_apparmor.c | 18 +- src/security/security_dac.c | 28 ++- src/security/security_selinux.c | 28 ++- src/security/virt-aa-helper.c | 11 +- src/util/virpci.c | 69 +++++++ src/util/virpci.h | 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 ++++ 28 files changed, 839 insertions(+), 50 deletions(-) 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

2 15

[PATCH 1/3] bhyve: implement SLIRP networking
by Roman Bogorodskiy 15 Dec '25

15 Dec '25

Bhyve supports SLIRP networking using the following syntax: -s 12:0,e1000,slirp,open Where "e1000" is a NIC model, "slirp" is the SLIRP backend and "open" specifies open mode where external network is available to the guest. The "open" mode is a recent addition in FreeBSD -CURRENT. Unfortunately, bhyve does not provide a way to probe whether the open mode is supported, so users will have to make sure it's supported on their own. For the reference, without the "open" mode, the guest will have no outside network connectivity. To make this mode useful, it is possible to configure forwarding from the host to the guest, but it is not covered by this patch. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/bhyve/bhyve_command.c | 6 +++- .../bhyvexml2argv-slirp.args | 10 ++++++ .../bhyvexml2argv-slirp.ldargs | 4 +++ .../bhyvexml2argvdata/bhyvexml2argv-slirp.xml | 21 ++++++++++++ tests/bhyvexml2argvtest.c | 1 + .../bhyvexml2xmlout-slirp.xml | 32 +++++++++++++++++++ tests/bhyvexml2xmltest.c | 1 + 7 files changed, 74 insertions(+), 1 deletion(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-slirp.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-slirp.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-slirp.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-slirp.xml diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c index e42e7b1ecc..b7e47084e6 100644 --- a/src/bhyve/bhyve_command.c +++ b/src/bhyve/bhyve_command.c @@ -93,9 +93,13 @@ bhyveBuildNetArgStr(const virDomainDef *def, goto cleanup; } break; + case VIR_DOMAIN_NET_TYPE_USER: + virCommandAddArg(cmd, "-s"); + virCommandAddArgFormat(cmd, "%d:0,%s,slirp,open", + net->info.addr.pci.slot, nic_model); + return 0; case VIR_DOMAIN_NET_TYPE_ETHERNET: case VIR_DOMAIN_NET_TYPE_DIRECT: - case VIR_DOMAIN_NET_TYPE_USER: case VIR_DOMAIN_NET_TYPE_VHOSTUSER: case VIR_DOMAIN_NET_TYPE_SERVER: case VIR_DOMAIN_NET_TYPE_CLIENT: diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-slirp.args b/tests/bhyvexml2argvdata/bhyvexml2argv-slirp.args new file mode 100644 index 0000000000..ff9a90ebc9 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-slirp.args @@ -0,0 +1,10 @@ +bhyve \ +-c 1 \ +-m 214 \ +-u \ +-H \ +-P \ +-s 0:0,hostbridge \ +-s 2:0,ahci,hd:/tmp/freebsd.img \ +-s 3:0,e1000,slirp,open \ +bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-slirp.ldargs b/tests/bhyvexml2argvdata/bhyvexml2argv-slirp.ldargs new file mode 100644 index 0000000000..5905f4b3e6 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-slirp.ldargs @@ -0,0 +1,4 @@ +bhyveload \ +-m 214 \ +-d /tmp/freebsd.img \ +bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-slirp.xml b/tests/bhyvexml2argvdata/bhyvexml2argv-slirp.xml new file mode 100644 index 0000000000..5cf13d2a20 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-slirp.xml @@ -0,0 +1,21 @@ +<domain type='bhyve'> + <name>bhyve</name> + <uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid> + <memory>219136</memory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + </os> + <devices> + <disk type='file'> + <driver name='file' type='raw'/> + <source file='/tmp/freebsd.img'/> + <target dev='hda' bus='sata'/> + <address type='drive' controller='0' bus='0' target='2' unit='0'/> + </disk> + <interface type='user'> + <model type='e1000'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + </devices> +</domain> diff --git a/tests/bhyvexml2argvtest.c b/tests/bhyvexml2argvtest.c index 650313c2da..ee3d677947 100644 --- a/tests/bhyvexml2argvtest.c +++ b/tests/bhyvexml2argvtest.c @@ -270,6 +270,7 @@ mymain(void) DO_TEST("sata-rotation-rate"); DO_TEST_FAILURE("disk-virtio-rotation-rate"); DO_TEST_FAILURE("disk-virtio-queue-opts"); + DO_TEST("slirp"); /* Address allocation tests */ DO_TEST("addr-single-sata-disk"); diff --git a/tests/bhyvexml2xmloutdata/bhyvexml2xmlout-slirp.xml b/tests/bhyvexml2xmloutdata/bhyvexml2xmlout-slirp.xml new file mode 100644 index 0000000000..44d2616f6c --- /dev/null +++ b/tests/bhyvexml2xmloutdata/bhyvexml2xmlout-slirp.xml @@ -0,0 +1,32 @@ +<domain type='bhyve'> + <name>bhyve</name> + <uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <disk type='file' device='disk'> + <driver name='file' type='raw'/> + <source file='/tmp/freebsd.img'/> + <target dev='hda' bus='sata'/> + <address type='drive' controller='0' bus='0' target='2' unit='0'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </controller> + <interface type='user'> + <mac address='52:54:00:00:00:00'/> + <model type='e1000'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + </devices> +</domain> diff --git a/tests/bhyvexml2xmltest.c b/tests/bhyvexml2xmltest.c index c2458b9fc4..0abc50b0de 100644 --- a/tests/bhyvexml2xmltest.c +++ b/tests/bhyvexml2xmltest.c @@ -122,6 +122,7 @@ mymain(void) DO_TEST_DIFFERENT("nvme"); DO_TEST_DIFFERENT("2-nvme-2-controllers"); DO_TEST_DIFFERENT("passthru-multiple-devs"); + DO_TEST_DIFFERENT("slirp"); /* Address allocation tests */ DO_TEST_DIFFERENT("addr-single-sata-disk"); -- 2.51.2

3 9

Question about error conditions for ACPI usage on aarch64
by Kazuhiro Abe (Fujitsu) 15 Dec '25

15 Dec '25

Hi all, We are currently working on CCA support. Due to CCA specifications, we are unable to use pflash with QEMU. Therefore, we intend to enable ACPI by specifying the UEFI firmware using the QEMU -bios option as follows: -machine virt,acpi=on -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd Using the above QEMU option, we can successfully boot VM. My understanding is that the above QEMU option could be translated by the following libvirt XML: <os> <type arch='aarch64' machine='virt-4.0'>hvm</type> <loader type="rom">/usr/share/qemu-efi-aarch64/QEMU_EFI.fd</loader> </os> <features> <acpi/> </features> However, this XML configuration results in a validation error. Specifically, the error occurs because def->os.firmware is VIR_DOMAIN_OS_DEF_FIRMWARE_NONE during the following check: src/qemu/qemu_validate.c: qemuValidateDomainDef() /* On aarch64, ACPI requires UEFI */ if (def->features[VIR_DOMAIN_FEATURE_ACPI] == VIR_TRISTATE_SWITCH_ON && def->os.arch == VIR_ARCH_AARCH64 && (def->os.firmware != VIR_DOMAIN_OS_DEF_FIRMWARE_EFI && !virDomainDefHasOldStyleUEFI(def))) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("ACPI requires UEFI on this architecture")); return -1; } It appears that a configuration that successfully boots QEMU directly is being rejected by libvirt. Could you please explain if there's a specific reason for this strict validation? We are particularly interested in why VIR_DOMAIN_OS_DEF_FIRMWARE_NONE also becomes a condition for this error. Best Regards, Kazuhiro Abe

3 9

[RFC v3 0/5] cover: RFE libvirt secret encryption on disk
by Arun Menon 02 Dec '25

02 Dec '25

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 service. virtsecretd service only starts after the new service generates a random encryption key. 3. Add a new secrets.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. Add encryption scheme or cipher attribute that will allow us to choose the last used cipher. 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 v3: - Secrets xml configuration no longer stores the encryption scheme, therefore not allowing the user to toggle between ciphers. - Removed unnecessary socket files of the new service. It now has a general configuration with which it starts. - Addressed review comments from Peter on coding style and design. - Loading of secrets is dependent on the file extension. Most recent cipher is used while saving the secrets. Changes in v2: - Corrected the encryption key length check. It should be 32. - Added a new patch that introduces the encryption scheme attribute. This will help us identify which secrets are encrypted. - A new systemd unit service file added that starts before virtsecretd, helping us to construct a random encryption key and pass it to the virtsecretd service. - Parsing logic of secrets.conf moved to a separate file. - Spec file changes, augeas. Arun Menon (5): util: Add support for GnuTLS decryption secret: Set up default encryption secret key for the virtsecretd service secret: Add secrets.conf configuration file and parse it secret: Add encryptionSchemeType attribute to store ciphers secret: Add functionality to load and save secrets in encrypted format include/libvirt/libvirt-secret.h | 20 +++ libvirt.spec.in | 7 + po/POTFILES | 1 + src/conf/meson.build | 1 + src/conf/secret_conf.h | 1 + src/conf/secret_config.c | 177 ++++++++++++++++++++++++ src/conf/secret_config.h | 38 +++++ src/conf/virsecretobj.c | 177 ++++++++++++++++++------ src/conf/virsecretobj.h | 13 +- src/libvirt_private.syms | 3 + src/meson.build | 1 + src/secret/libvirt_secrets.aug | 40 ++++++ src/secret/meson.build | 42 ++++++ src/secret/secret-init-encryption.in | 10 ++ src/secret/secret_driver.c | 27 +++- src/secret/secrets.conf.in | 12 ++ src/secret/test_libvirt_secrets.aug.in | 6 + src/secret/virtsecretd.service.extra.in | 8 ++ src/util/vircrypto.c | 126 ++++++++++++++++- src/util/vircrypto.h | 8 ++ src/util/virsecret.c | 4 + src/util/virsecret.h | 1 + tests/vircryptotest.c | 65 +++++++++ 23 files changed, 735 insertions(+), 53 deletions(-) create mode 100644 src/conf/secret_config.c create mode 100644 src/conf/secret_config.h create mode 100644 src/secret/libvirt_secrets.aug create mode 100644 src/secret/secret-init-encryption.in create mode 100644 src/secret/secrets.conf.in create mode 100644 src/secret/test_libvirt_secrets.aug.in -- 2.51.1

3 21

[PATCH 0/8] Avoid changing const string via strchr() and friends
by Michal Privoznik 02 Dec '25

02 Dec '25

This stems from the discussion here: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/HVMC… Green pipeline here: https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/2183169334 Michal Prívozník (8): vircommand: Update documentation to virCommandSetDryRun() virstringtest: Introduce a test for virSkipSpacesBackwards() virfirewalltest: Introduce testIPtablesSetupPrivateChains() virSkipSpacesBackwards: Turn @endp into const iptablesPrivateChainCreate: Rename @tmp variable iptablesPrivateChainCreate: Switch to STRSKIP() iptablesPrivateChainCreate: Avoid modifying const string lib: Avoid changing const strings via strchr() and friends src/interface/interface_backend_udev.c | 2 +- src/libxl/xen_common.c | 10 +- src/libxl/xen_xm.c | 10 +- src/network/meson.build | 1 + src/network/network_iptables.c | 33 ++++--- src/node_device/node_device_udev.c | 2 +- src/nwfilter/nwfilter_ebiptables_driver.c | 4 +- src/qemu/qemu_monitor_json.c | 2 +- src/qemu/qemu_nbdkit.c | 2 +- src/rpc/virnetsshsession.c | 5 +- src/storage/storage_util.c | 2 +- src/storage_file/storage_source.c | 4 +- src/util/vircgroup.c | 2 +- src/util/vircommand.c | 10 +- src/util/virfile.c | 2 +- src/util/virstoragefile.c | 4 +- src/util/virstring.c | 20 ++-- src/util/virstring.h | 2 +- src/util/virsysinfo.c | 22 ++--- src/util/virxml.c | 3 +- src/vmware/vmware_conf.c | 2 +- tests/meson.build | 9 +- tests/virfirewalltest.c | 111 ++++++++++++++++++++++ tests/virstringtest.c | 48 ++++++++++ tools/vsh.c | 6 +- 25 files changed, 252 insertions(+), 66 deletions(-) -- 2.51.2

3 11

[RFC PATCH v3 0/4] qemu: Implement support for EGM
by Nathan Chen 01 Dec '25

01 Dec '25

The Grace SOC introduces Extended GPU Memory (EGM) [3], a feature that enables GPUs to efficiently access system memory within and across nodes. This patch series adds support for virtualizing EGM (vEGM) in libvirt, allowing VMs to utilize dedicated EGM memory regions through ACPI. This patch series is a follow-up RFC to the second EGM RFC series [0], to gather feedback from the libvirt community on the overall approach and implementation details. While kernel EGM driver support and QEMU acpi-egm-memory device support are not yet upstream, reference implementations are available [1][2] to enable testing and validation of the libvirt integration. Any community feedback is appreciated. Background and Use Cases ========================= EGM allows host memory to be partitioned into two regions: 1. Standard memory for Host OS usage 2. EGM region assigned to VMs as their system memory This technology enables various high-performance computing scenarios [3]: - Large memory pools for AI/ML workloads - High-performance computing applications - Memory extension for systems with limited main memory - GPU-accelerated workloads requiring large addressable memory Implementation Overview ======================= This series adds a new memory device model VIR_DOMAIN_MEMORY_MODEL_EGM with 'path' source attribute and 'pciDev' target attribute to denote host EGM device backing path and PCI device alias to associate the vEGM with, respectively. For instance, given the XML stanzas below: <memory model='egm' access='shared'> <source> <path>/dev/egm4</path> </source> <target> <size unit='KiB'>8388608</size> <node>0</node> <pciDev>ua-hostdev0</pciDev> </target> </memory> <memory model='egm' access='shared'> <source> <path>/dev/egm5</path> </source> <target> <size unit='KiB'>8388608</size> <node>1</node> <pciDev>ua-hostdev1</pciDev> </target> </memory> The corresponding qemu command line will include the following arguments: -object '{"qom-type":"memory-backend-file","id":"memegm0","mem-path":"/dev/egm4","share":true,"prealloc":true,"size":8589934592}' \ -object acpi-egm-memory,id=egm0,pci-dev=ua-hostdev0,node=0 \ -object '{"qom-type":"memory-backend-file","id":"memegm1","mem-path":"/dev/egm5","share":true,"prealloc":true,"size":8589934592}' \ -object acpi-egm-memory,id=egm1,pci-dev=ua-hostdev1,node=1 \ -numa node,nodeid=0,cpus=0-1,memdev=memegm4 \ -numa node,nodeid=1,cpus=2-3,memdev=memegm5 \ For a system where multiple GPUs are associated with a single host socket/NUMA node/EGM chardev, we consolidate the memory backing into a single memory-backend-file object per host EGM chardev. For instance, given the XML stanzas below: <memory model='egm' access='shared'> <source> <path>/dev/egm4</path> </source> <target> <size unit='KiB'>8388608</size> <node>0</node> <pciDev>ua-hostdev0</pciDev> </target> </memory> <memory model='egm' access='shared'> <source> <path>/dev/egm4</path> </source> <target> <size unit='KiB'>8388608</size> <node>0</node> <pciDev>ua-hostdev1</pciDev> </target> </memory> The corresponding qemu command line will include the following arguments: -object '{"qom-type":"memory-backend-file","id":"memegm0","mem-path":"/dev/egm4","share":true,"prealloc":true,"size":17179869184}' \ -object acpi-egm-memory,id=egm0,pci-dev=ua-hostdev0,node=0 \ -object acpi-egm-memory,id=egm1,pci-dev=ua-hostdev1,node=0 \ -numa node,nodeid=0,cpus=0-4,memdev=memegm0 \ Changes from RFCv2: - Decouple host EGM chardev name from guest EGM ID - Consolidate all acpi-egm-memory objects' memory into a single memory-backend-file per EGM chardev specified. Changes from RFCv1: - Use existing memory device infrastructure to represent EGM configuration - Added support for multiple EGM devices This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/egm-11-24-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/6RU7… [1] https://github.com/ianm-nv/qemu/tree/6.8_ghvirt_egm_may2025 [2] https://github.com/NVIDIA/QEMU/commit/32db1b74fb99c0571724c7e69485e89098c14… [3] https://developer.nvidia.com/blog/nvidia-grace-hopper-superchip-architectur… Ian May (1): tests: Add qemuxmlconftest for ACPI EGM memory device Nathan Chen (3): conf: Support EGM memory device model qemu: Add cgroup, namespace, and seclabel setup for EGM memory device model qemu: Add qemu CLI support for EGM docs/formatdomain.rst | 18 +- src/conf/domain_conf.c | 34 +++- src/conf/domain_conf.h | 7 + src/conf/domain_postparse.c | 6 +- src/conf/domain_validate.c | 15 ++ src/conf/schemas/domaincommon.rng | 6 + src/qemu/qemu_alias.c | 7 +- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 10 ++ src/qemu/qemu_command.c | 158 ++++++++++++++++-- src/qemu/qemu_domain.c | 15 +- src/qemu/qemu_domain_address.c | 3 + src/qemu/qemu_driver.c | 1 + src/qemu/qemu_hotplug.c | 1 + src/qemu/qemu_monitor_json.c | 1 + src/qemu/qemu_namespace.c | 3 + src/qemu/qemu_postparse.c | 1 + src/qemu/qemu_process.c | 2 + src/qemu/qemu_validate.c | 6 + src/security/apparmor/usr.sbin.libvirtd.in | 3 + src/security/security_apparmor.c | 2 + src/security/security_dac.c | 8 + src/security/security_selinux.c | 6 + src/security/virt-aa-helper.c | 4 + src/util/virfile.h | 2 +- tests/meson.build | 1 + tests/qemuegmmock.c | 67 ++++++++ .../acpi-egm-memory.aarch64-latest.args | 47 ++++++ .../acpi-egm-memory.aarch64-latest.xml | 124 ++++++++++++++ tests/qemuxmlconfdata/acpi-egm-memory.xml | 124 ++++++++++++++ tests/qemuxmlconftest.c | 8 +- 32 files changed, 672 insertions(+), 21 deletions(-) create mode 100644 tests/qemuegmmock.c create mode 100644 tests/qemuxmlconfdata/acpi-egm-memory.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/acpi-egm-memory.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/acpi-egm-memory.xml -- 2.43.0

2 8

[PATCH 0/3] Fix VMX-* feature detection from MSR
by Hector Cao 01 Dec '25

01 Dec '25

Currently, libvirt is unable to detect the CPU model of recent Intel CPUs (like Granite Rapids) with VMX-* features specified in the MSRs (Model Specific Registers). This is due to the wrong parsing of these VMX-* features from the MSR values. This series of 3 commits allow to fix the MSR VMX-* feature detection. This has been tested successfully on a platform equipped with Intel Granite Rapids CPU. Hector Cao (3): cpu_map: fix sync script to extract correctly vmx-* features cpu_map: update vmx-* features cputest : fix test failures due to VMX-* feature update src/cpu_map/sync_qemu_features_i386.py | 19 +++ src/cpu_map/x86_features.xml | 136 +++++++++--------- .../x86_64-cpuid-Atom-P5362-2-enabled.xml | 10 +- .../x86_64-cpuid-Atom-P5362-enabled.xml | 10 +- .../x86_64-cpuid-Cooperlake-enabled.xml | 10 +- .../x86_64-cpuid-Core-i7-1270P-enabled.xml | 10 +- .../x86_64-cpuid-Core-i7-1365U-enabled.xml | 10 +- .../x86_64-cpuid-Core-i7-8550U-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-6731E-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-6788P-disabled.xml | 1 + .../x86_64-cpuid-Xeon-6788P-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-6788P-guest.xml | 17 ++- .../x86_64-cpuid-Xeon-6788P-host.xml | 17 ++- ...x86_64-cpuid-Xeon-Bronze-3408U-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-E3-1270-v5-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-Gold-6152-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-Gold-6530-enabled.xml | 10 +- ...86_64-cpuid-Xeon-Platinum-9242-enabled.xml | 10 +- ...x86_64-cpuid-Xeon-Silver-4214R-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-w7-3465X-enabled.xml | 10 +- 20 files changed, 181 insertions(+), 159 deletions(-) -- 2.45.2

3 8

[PATCH] NEWS: Mention CVE-2025-13193 and improvements for block stats/config and backups
by Peter Krempa 28 Nov '25

28 Nov '25

From: Peter Krempa <pkrempa(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 879e9e8448..91ed53ba7e 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -29,6 +29,14 @@ v11.10.0 (unreleased) identification parts of the XML definition (which is needed to perform the checks) and full parsing is done only after checking all ACLs. + * CVE-2025-13193: Incorrect permissions on images after external snapshot of an inactive VM + + The overlay ``qcow2`` images which are created as part of creation of an + external snapshot of an inactive VM had world-readable (644) permissions + which would allow unauthorized users to see contents of blocks written by + the VM after snapshot was taken. Libvirt now sets proper umask so that + the images are created with 600 mode. + * **Removed features** * **New features** @@ -39,6 +47,11 @@ v11.10.0 (unreleased) feature requires Qemu version 10.2.0 or later and is available on Linux hosts where the /dev/mshv is present. + * Add more statistics for block devices on QEMU domains + + The block devices now report optimal access request sizes as well as + statistics such as the queue depth. + * **Improvements** * bhyve: VNC ``wait`` attribute support @@ -57,6 +70,12 @@ v11.10.0 (unreleased) The virt-host-validate tool will now report extra details when certain checks pass. + * qemu: Allow backup jobs to continue if guest OS shuts down + + When starting a backup job users can now use a flag which prevents the VM + to be completely cleaned up if the guest OS shuts down while the backup is + running so that the backup can be finalized. + * **Bug fixes** * ch: Use correct domain definition in chDomainGetXMLDesc() @@ -83,6 +102,13 @@ v11.10.0 (unreleased) if the QEMU binary had it built-in. It is now limited to only platforms with the TDX kernel feature available for use. + * qemu: set ``detect_zeroes`` for all backing chain layers + + Some block jobs (snapshots, block commit) could modify the backing chain in + a way where ``detect_zeroes`` would no longer be honoured. We now set + it for all images in the backing chain, so that it will behave correctly + even after those operations. + v11.9.0 (2025-11-03) ==================== -- 2.52.0

2 1

[PATCH] formatdomaincaps: Fix typo in Hyper-V Enlightenments section
by Jiri Denemark 28 Nov '25

28 Nov '25

From: Jiri Denemark <jdenemar(a)redhat.com> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- docs/formatdomaincaps.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatdomaincaps.rst b/docs/formatdomaincaps.rst index 32dc09d41e..8b4f0ecff3 100644 --- a/docs/formatdomaincaps.rst +++ b/docs/formatdomaincaps.rst @@ -871,7 +871,7 @@ are supported. The ``features`` enum corresponds to the ``<hyperv/>`` element (well, its children) as documented in `Hypervisor features <formatdomain.html#hypervisor-features>`__. The ``defaults`` element then contains child elements describing default values as reported by hypervisor, -e.h. whether direct or extended TLB flushes are available. :since:`(since +e.g. whether direct or extended TLB flushes are available. :since:`(since 11.9.0)` Launch security -- 2.51.1

2 1

[PATCH] NEWS: Fix incoming migration to QEMU 10.0.0
by Jiri Denemark 28 Nov '25

28 Nov '25

From: Jiri Denemark <jdenemar(a)redhat.com> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- NEWS.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index c742954091..d5028d230d 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -43,6 +43,13 @@ v11.10.0 (unreleased) subdirectory, the ESX driver would have failed to parse that and an error was reported when obtaining domain XML. This is now fixed. + * qemu: Fix incoming migration to QEMU 10.0.0 and newer + + Due to a change in the way QEMU 10.0.0 reports the state of "ht" CPU + feature, incoming migration of a domain with multiple CPU threads would + fail with "guest CPU doesn't match specification: extra features: ht" + error. + v11.9.0 (2025-11-03) ==================== -- 2.51.1

2 1

[PATCH] NEWS: Add CVE-2025-12748
by Martin Kletzander 28 Nov '25

28 Nov '25

From: Martin Kletzander <mkletzan(a)redhat.com> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- NEWS.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index c742954091df..8cc6e698ca25 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -13,6 +13,22 @@ v11.10.0 (unreleased) * **Security** + * CVE-2025-12748: Denial of service by some ACL-limited accounts + + Parsing of user provided XMLs in APIs which needed the identification + information from those XML definitions was done in full before ACL checks + were performed. Some valid, but useless, definitions could cause allocation + of too much memory, leading to denial of service. APIs which do equate to + full root access (such as ``domain:write``), and were parsing XML + definitions in full before performing ACL checks could, potentially, be + exploited in a way that would allow users (which were about to be denied the + API call) to cause aforementioned overallocation even before the ACL checks + were performed. + + A change was made so that parsing before ACL checks are done only for the + identification parts of the XML definition (which is needed to perform the + checks) and full parsing is done only after checking all ACLs. + * **Removed features** * **New features** -- 2.52.0

2 2