December 2025 - Devel - libvirt List Archives

[PATCH v2 0/2] qemu_dbus: Escape path to dbus-daemon socket if needed
by Michal Privoznik 18 Dec '25

18 Dec '25

v2 of: $(you know which patch, the list archive is down) diff to v1: - New function to escape a string according to DBus rules is introduced (virStringEscapeDBus()) and used. Michal Prívozník (2): util: Introduce virStringEscapeDBus() qemu_dbus: Escape path to dbus-daemon socket if needed src/libvirt_private.syms | 1 + src/qemu/qemu_dbus.c | 4 ++- src/util/virstring.c | 64 ++++++++++++++++++++++++++++++++++++++++ src/util/virstring.h | 1 + tests/virstringtest.c | 43 +++++++++++++++++++++++++++ 5 files changed, 112 insertions(+), 1 deletion(-) -- 2.51.2

1 2

[PATCH] qemu_dbus: Escape path to dbus-daemon socket if needed
by Michal Privoznik 18 Dec '25

18 Dec '25

From: Michal Privoznik <mprivozn(a)redhat.com> According to [1] there are only few characters allowed in the path to the daemon socket (alphanum and some punctuation; notably, space is missing on the list). The rest must be escaped by '%NN' notation. Fortunately, g_uri_escape_string() with some carefully selected input values is able to escape the path. Almost - it considers tilde valid but DBus doesn't. Well, let's hope nobody has tilde in domain name. 1: https://gitlab.freedesktop.org/dbus/dbus/-/blob/2dee5236088bcf690ba92b743a5… Closes: https://gitlab.com/libvirt/libvirt/-/issues/834 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_dbus.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_dbus.c b/src/qemu/qemu_dbus.c index 625884ad46..db0757b71d 100644 --- a/src/qemu/qemu_dbus.c +++ b/src/qemu/qemu_dbus.c @@ -119,6 +119,12 @@ static int qemuDBusWriteConfig(const char *filename, const char *path, bool privileged) { g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER; + /* Escape @path pointing to socket where the dbus-daemon is going to listen + * to. Valid characters are alphanumeric, '-', '_', '/', '\\', '*' and '.'. + * The rest must be URI escaped. g_uri_escape_string() treads alphanumeric, + * '-', '.', '_' and '~' as valid. + */ + g_autofree char *escapedPath = g_uri_escape_string(path, "/\\*", false); g_autofree char *config = NULL; virBufferAddLit(&buf, "<!DOCTYPE busconfig PUBLIC \"-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN\"\n"); @@ -127,7 +133,7 @@ qemuDBusWriteConfig(const char *filename, const char *path, bool privileged) virBufferAdjustIndent(&buf, 2); virBufferAddLit(&buf, "<type>org.libvirt.qemu</type>\n"); - virBufferAsprintf(&buf, "<listen>unix:path=%s</listen>\n", path); + virBufferAsprintf(&buf, "<listen>unix:path=%s</listen>\n", escapedPath); virBufferAddLit(&buf, "<auth>EXTERNAL</auth>\n"); virBufferAddLit(&buf, "<policy context='default'>\n"); -- 2.51.2

4 4

[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] rpm: disable -Werror on ELN builds
by Daniel P. Berrangé 18 Dec '25

18 Dec '25

From: Daniel P. Berrangé <berrange(a)redhat.com> The ELN build root performs rebuilds of Fedora rawhide packages with %{rhel} set instead of %{fedora}. The vast majority of the time this will "do the right thing", but when we control -Dwerror we chose to enable -Werror on RHEL on the basis that the GCC toolchain is stable and thus we don't expect new warnings to appear. That does not hold true for ELN which tracks rawhide GCC. Thus we have the rare situation where we should explicitly check %{eln} not just %{rhel}. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- libvirt.spec.in | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index ccfe75135b..22c9975d9f 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -263,8 +263,9 @@ # RHEL releases provide stable tool chains and so it is safe to turn # compiler warning into errors without being worried about frequent -# changes in reported warnings -%if 0%{?rhel} +# changes in reported warnings. ELN is a rebuild of Rawhide so should +# be treated as unstable for this flag +%if 0%{?rhel} && !0%{?eln} %define enable_werror -Dwerror=true %else %define enable_werror -Dwerror=false -Dgit_werror=disabled -- 2.52.0

2 1

[PATCH v2 0/2] bhyve: implement SLIRP networking
by Roman Bogorodskiy 18 Dec '25

18 Dec '25

Was going to push it right away, but there were a little more changes than I expected, so sending v2. Changes from v1: - Patch 1/3 (implementation) updated to pass "mac=" MAC address configuration for the slirp interface, - Patch 2/3 updated to remove error if MAC address is specified and squashed into 1/3 as there was only a single code chunk left. Roman Bogorodskiy (2): bhyve: implement SLIRP networking docs: drvbhyve: document SLIRP networking docs/drvbhyve.rst | 24 ++++++++++++++ src/bhyve/bhyve_command.c | 10 ++++-- src/bhyve/bhyve_domain.c | 12 ++++++- .../bhyvexml2argv-slirp-ip.xml | 22 +++++++++++++ .../bhyvexml2argv-slirp-mac-addr.args | 10 ++++++ .../bhyvexml2argv-slirp-mac-addr.ldargs | 4 +++ .../bhyvexml2argv-slirp-mac-addr.xml | 22 +++++++++++++ .../bhyvexml2argv-slirp.args | 10 ++++++ .../bhyvexml2argv-slirp.ldargs | 4 +++ .../bhyvexml2argvdata/bhyvexml2argv-slirp.xml | 21 ++++++++++++ tests/bhyvexml2argvtest.c | 3 ++ .../bhyvexml2xmlout-slirp.xml | 32 +++++++++++++++++++ tests/bhyvexml2xmltest.c | 1 + 13 files changed, 172 insertions(+), 3 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-slirp-ip.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-slirp-mac-addr.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-slirp-mac-addr.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-slirp-mac-addr.xml 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 -- 2.51.2

2 5

[PATCH] hw/arm: Deprecate legacy VirtIO devices on big-endian guests
by Philippe Mathieu-Daudé 17 Dec '25

17 Dec '25

We couldn't find a way (guest OS with VirtIO drivers) to test a legacy VirtIO device on a ARM vCPU running in big-endian. Deprecate for the v11.0 release, giving 1 year to users who really care to contribute functional tests. Suggested-by: Alex Bennée <alex.bennee(a)linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> --- docs/about/deprecated.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index ac31a2bce42..3a69facb0f1 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -515,6 +515,17 @@ It was implemented as a no-op instruction in TCG up to QEMU 9.0, but only with ``-cpu max`` (which does not guarantee migration compatibility across versions). +VirtIO devices +'''''''''''''' + +Legacy VirtIO devices on Big-Endian ARM architecture (since 11.0) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There are no functional tests for legacy virtio devices used by ARM +machines running in big-endian order, which makes harder to maintain +the code path while the code base evolve. + + Backwards compatibility ----------------------- -- 2.52.0

4 4

[PATCH v3 21/51] qapi/migration: Deprecate capabilities commands
by Fabiano Rosas 16 Dec '25

16 Dec '25

The concept of capabilities is being merged into the concept of parameters. From now on, the commands that handle capabilities are deprecated in favor of the commands that handle parameters. Affected commands: - migrate-set-capabilities - query-migrate-capabilities Reviewed-by: Markus Armbruster <armbru(a)redhat.com> Reviewed-by: Peter Xu <peterx(a)redhat.com> Signed-off-by: Fabiano Rosas <farosas(a)suse.de> --- docs/about/deprecated.rst | 10 ++++++++++ migration/migration-hmp-cmds.c | 6 ++++++ qapi/migration.json | 16 ++++++++++++++-- 3 files changed, 30 insertions(+), 2 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index ac31a2bce4..1949508efa 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -588,3 +588,13 @@ command documentation for details on the ``fdset`` usage. The ``zero-blocks`` capability was part of the block migration which doesn't exist anymore since it was removed in QEMU v9.1. + +``migrate-set-capabilities`` command (since 10.2) +''''''''''''''''''''''''''''''''''''''''''''''''' + +Use ``migrate-set-parameters`` instead. + +``query-migrate-capabilities`` command (since 10.2) +''''''''''''''''''''''''''''''''''''''''''''''''''' + +Use ``query-migrate-parameters`` instead. diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c index 28b48c34bf..7e5ac57da5 100644 --- a/migration/migration-hmp-cmds.c +++ b/migration/migration-hmp-cmds.c @@ -298,6 +298,9 @@ void hmp_info_migrate_capabilities(Monitor *mon, const QDict *qdict) { MigrationCapabilityStatusList *caps, *cap; + warn_report("info migrate_capabilities is deprecated;" + " use info migrate_parameters instead"); + caps = qmp_query_migrate_capabilities(NULL); if (caps) { @@ -705,6 +708,9 @@ void hmp_migrate_set_capability(Monitor *mon, const QDict *qdict) MigrationCapabilityStatus *value; int val; + warn_report("migrate_set_capability is deprecated;" + " use migrate_set_parameter instead"); + val = qapi_enum_parse(&MigrationCapability_lookup, cap, -1, &err); if (val < 0) { goto end; diff --git a/qapi/migration.json b/qapi/migration.json index fcbb699a47..76a1e03f2f 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -570,6 +570,11 @@ # # @capabilities: json array of capability modifications to make # +# Features: +# +# @deprecated: This command is deprecated. Use migrate-set-parameters +# instead. +# # Since: 1.2 # # .. qmp-example:: @@ -579,13 +584,19 @@ # <- { "return": {} } ## { 'command': 'migrate-set-capabilities', - 'data': { 'capabilities': ['MigrationCapabilityStatus'] } } + 'data': { 'capabilities': ['MigrationCapabilityStatus'] }, + 'features': ['deprecated'] } ## # @query-migrate-capabilities: # # Return information about the current migration capabilities status # +# Features: +# +# @deprecated: This command is deprecated. Use +# query-migrate-parameters instead. +# # Since: 1.2 # # .. qmp-example:: @@ -601,7 +612,8 @@ # {"state": false, "capability": "x-colo"} # ]} ## -{ 'command': 'query-migrate-capabilities', 'returns': ['MigrationCapabilityStatus']} +{ 'command': 'query-migrate-capabilities', 'returns': ['MigrationCapabilityStatus'], + 'features': ['deprecated'] } ## # @MultiFDCompression: -- 2.51.0

1 0

[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

[PATCH] util: json: Increase JSON nesting limit when parsing to 300
by Peter Krempa 12 Dec '25

12 Dec '25

From: Peter Krempa <pkrempa(a)redhat.com> The default in json-c is 32 which is too low to accomodate the 200 snapshot layers we supported historically in the qemu driver (200 is picked based on the 256 layer limit in libxml). The response to 'query-block' is otherwise too low and we fail to start the VM when there's around 26 images in a backing chain. 'json_tokener_new_ex' is supported since json-c 0.11 and we require at least 0.14. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- I've also figured out that we don't actually care about the backing image information so I've proposed a 'flat' mode for 'query-block' in qemu similarly to what we do for 'query-named-block-nodes': https://mail.gnu.org/archive/html/qemu-block/2025-12/msg00104.html src/util/virjson.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/util/virjson.c b/src/util/virjson.c index a799707c16..454bd657be 100644 --- a/src/util/virjson.c +++ b/src/util/virjson.c @@ -1466,7 +1466,15 @@ virJSONValueFromString(const char *jsonstring) VIR_DEBUG("string=%s", jsonstring); - tok = json_tokener_new(); + /* When creating the tokener we need to specify the limit of the nesting + * depth of JSON objects. The default in json-c is 32. Since we need to + * support at least 200 layers of snapshots (the limit is based on a + * conservative take on the 256 layer nesting limit for XML in libxml), for + * which we have internal checks, we also need to set the JSON limit to + * be able to parse qemu responses for such a deeply nested snapshot list. + * '300' is picked a sa conservative buffer on top of the 200 layers plus + * some of the extra wrappers that qemu adds*/ + tok = json_tokener_new_ex(300); if (!tok) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("failed to create JSON tokener")); -- 2.52.0

2 2