December 2025 - Devel - libvirt List Archives

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

17 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 15 Dec '25

15 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 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

[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

Re: [RFC PATCH 2/9] MAINTAINERS: fix libvirt entry
by Philippe Mathieu-Daudé 12 Dec '25

12 Dec '25

On 11/12/25 19:01, Alex Bennée wrote: > We have a particular tag for lists so lets use it. > > Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 05b644cfc9b..a3fdc4ca911 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4466,7 +4466,7 @@ F: gitdm.config > F: contrib/gitdm/* > > Incompatible changes > -R: devel(a)lists.libvirt.org > +L: devel(a)lists.libvirt.org Maybe keep both? See: commit b02c9bc35a03c099600693d6909f4566078880b8 Author: Markus Armbruster <armbru(a)redhat.com> Date: Mon Jul 16 09:32:26 2018 +0200 MAINTAINERS: New section "Incompatible changes", copy libvir-list Libvirt developers would like to be copied on patches to qemu-doc appendix "Deprecated features". Do them the favor. Signed-off-by: Markus Armbruster <armbru(a)redhat.com> Message-Id: <20180716073226.21127-3-armbru(a)redhat.com> Reviewed-by: Thomas Huth <thuth(a)redhat.com> Reviewed-by: Cornelia Huck <cohuck(a)redhat.com> Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com> diff --git a/MAINTAINERS b/MAINTAINERS index 20eef3cb61c..666e9368126 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2194,6 +2194,10 @@ M: Daniel P. Berrange <berrange(a)redhat.com> S: Odd Fixes F: docs/devel/build-system.txt +Incompatible changes +R: libvir-list(a)redhat.com +F: qemu-deprecated.texi

3 2

[PATCH 0/5] cover: RFE libvirt secret encryption on disk
by Arun Menon 12 Dec '25

12 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. The new test added works fine because during test execution, we use the mock implementation of virRandomBytes while generating the iv and the key. 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 secret.conf configuration file that helps user to set a. secrets_encryption_key - allows the user to specify the encryption key file path, in case the default key is not to be used. b. encrypt_data - set to 0 or 1. If set to 1, then the newly added secrets will be encrypted. 4. Add encryption scheme or cipher attribute that will allow us to choose the last used cipher. New modes can be added to the enum. 5. Once we have the encryption key, and a reliable way to tell the daemon what encryption scheme the secret object must use, 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 RFC: https://patchew.org/Libvirt/20251127072232.38426-1-armenon@redhat.com/ --- Changes in v1: - Previously, encrypt_data was set to 1 regardless of what is present in the secrets config file. This is now changed. encrypt_data is first read from the config file, and it is set to 1 only if secrets_encryption_key is not NULL or if systemd credential named "secrets-encryption-key" exists. - Rename from secrets.conf to secret.conf. Move secrets_config.c from src/conf to src/secret/ - Add a special error code 'VIR_ERR_INVALID_ENCR_KEY_SECRET' for when the secret key length is invalid. - Add the 2 directives to load credential into libvirtd service as well. Rename unit file name from secret-init-encryption.in to virt-secret-init-encryption.service.in. - Remove unnecessary configuration settings and make it inline. Arun Menon (5): util: Add support for GnuTLS decryption secret: Set up default encryption secret key for the virtsecretd service secret: Add secret.conf configuration file and parse it secret: Add encryptionSchemeType attribute to store ciphers secret: Add functionality to load and save secrets in encrypted format include/libvirt/virterror.h | 1 + libvirt.spec.in | 7 + po/POTFILES | 1 + src/conf/secret_conf.c | 6 + src/conf/secret_conf.h | 9 + src/conf/virsecretobj.c | 184 ++++++++++++++---- src/conf/virsecretobj.h | 18 +- src/libvirt_private.syms | 1 + src/meson.build | 1 + src/remote/libvirtd.service.in | 2 + src/secret/libvirt_secrets.aug | 40 ++++ src/secret/meson.build | 34 ++++ src/secret/secret.conf.in | 14 ++ src/secret/secret_config.c | 171 ++++++++++++++++ src/secret/secret_config.h | 40 ++++ src/secret/secret_driver.c | 34 +++- src/secret/test_libvirt_secrets.aug.in | 6 + .../virt-secret-init-encryption.service.in | 7 + src/secret/virtsecretd.service.extra.in | 8 + src/util/vircrypto.c | 126 +++++++++++- src/util/vircrypto.h | 8 + src/util/virerror.c | 3 + tests/vircryptotest.c | 65 +++++++ 23 files changed, 736 insertions(+), 50 deletions(-) create mode 100644 src/secret/libvirt_secrets.aug create mode 100644 src/secret/secret.conf.in create mode 100644 src/secret/secret_config.c create mode 100644 src/secret/secret_config.h create mode 100644 src/secret/test_libvirt_secrets.aug.in create mode 100644 src/secret/virt-secret-init-encryption.service.in -- 2.51.1

2 9