November 2025 - Devel - libvirt List Archives

[PATCH v1 0/4] Remove AST2700 A0
by Jamin Lin 31 Dec '25

31 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 16 Dec '25

16 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 8

[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 02 Dec '25

02 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