February 2026 - Devel - libvirt List Archives

[RFC PATCH v5 0/5] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe 27 Oct '26

27 Oct '26

Hi, all. This patch adds Arm CCA support to QEMU driver for aarch64 system. CCA is an abbreviation for Arm Confidential Compute Architecture feature, it enhances the virtualization capabilities of the platform by separating the management of resources from access to those resources. We are not yet at the stage where we can merge this patch as host Linux/QEMU support is not yet merged, but I would like to receive reviews and comments on the overall direction. Changes in v5: - Changed the target QEMU binary (Linaro's CCA/v10 version with added QMP functionality) - Changed the following changes to the CCA QMP command definitions: - QMP command name: query-rme-guest-capabilities - CCA capabilities info - Add ARM CCA support to firmware feature. [summary] At this stage, all you can do is getting the CCA capability with the virsh domcapabilities command and start the CCA VM with the virsh create command. capability info uses QEMU QMP to query QEMU options. The option that exists now is for selecting a hash algorithm. QEMU QMP sections currently only contains a single member, but is wrapped in sections for expansion. [Capability example] Execution results of 'virsh domcapability" on QEMU <domaincapabilities> ... <features> ... </sgx> <cca supported='yes'> <enum name='measurement-algo'> <value>sha256</value> <value>sha512</value> </enum> </cca> <hyperv supported='yes'> ... </features> </domaincapabilities> [XML example] <domain> ... <launchsecurity type='cca'> <measurement-algo>sha256</measurement-algo> </launchsecurity> ... </domain> [limitations/tests] To obtain capability info, it is necessary to support the QEMU QMP command, (See "[software version]"below). The JSON file for the CCA firmware feature has not yet been provided by the distributor. For CCA support, the equivalent of the following JSON file must be placed in /usr/share/qemu: tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json We have confirmed that the added tests (qemucapabilitiestest, domaincapstest and qemuxmlconftest) and the CCA VM startup test (starting the CCA VM from the virsh create command) passed. The "personalization-value" and "measurement-log" parameters that exist in the current Linaro QEMU cca/latest branch will not be specified as CCA VM startup parameters with the virsh create command. [software version] I followed the steps in Linaro's blog below. https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an… The QEMU used was enhanced with CCA QMP command and found at: https://gitlab.com/Linaro/dcap/qemu/-/commits/cca/latest RFC v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/V4S5… RFC v2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5VZ… RFC v3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LLWA… RFC v4 https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3WAW… Signed-off-by: Kazuhiro Abe fj1078ii(a)aa.jp.fujitsu.com Akio Kakuno (3): src: Add ARM CCA support in qemu driver to launch VM src: Add ARM CCA support in domain capabilities command src: Add ARM CCA support in domain schema Kazuhiro Abe (2): src: Add ARM CCA support in firmware feature tests: Adds Arm CCA support docs/formatdomain.rst | 46 + docs/formatdomaincaps.rst | 27 +- src/conf/domain_capabilities.c | 48 + src/conf/domain_capabilities.h | 12 + src/conf/domain_conf.c | 25 + src/conf/domain_conf.h | 9 + src/conf/domain_validate.c | 1 + src/conf/schemas/domaincaps.rng | 36 + src/conf/schemas/domaincommon.rng | 26 + src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 146 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 30 + src/qemu/qemu_driver.c | 2 + src/qemu/qemu_firmware.c | 18 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 111 + src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 4 + src/security/security_dac.c | 2 + .../qemu_10.1.0-virt.aarch64+armrme.xml | 250 + .../qemu_10.1.0.aarch64+armrme.xml | 250 + tests/qemucapabilitiesdata/README.rst | 5 + .../caps_10.1.0_aarch64+armrme.replies | 37727 ++++++++++++++++ .../caps_10.1.0_aarch64+armrme.xml | 518 + .../qemu/firmware/50-edk2-aarch64-armcca.json | 24 + tests/qemufirmwaretest.c | 3 + ...ch-security-cca.aarch64-latest+armrme.args | 30 + ...nch-security-cca.aarch64-latest+armrme.xml | 24 + tests/qemuxmlconfdata/launch-security-cca.xml | 16 + tests/qemuxmlconftest.c | 2 + 36 files changed, 39423 insertions(+), 1 deletion(-) create mode 100644 tests/domaincapsdata/qemu_10.1.0-virt.aarch64+armrme.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0.aarch64+armrme.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.xml create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml -- 2.43.0

2 6

[libvirt] [PATCH 00/23] Fix host-model if the chosen CPU model has more features in QEMU compared to our cpu_map.xml
by Jiri Denemark 15 Oct '26

15 Oct '26

When decoding CPUID data to virCPUDef we need to be careful about using a CPU model which cannot be directly used on the current host. Normally, libvirt would notice the features which prevent the model from being usable and it would disable them in the computed virCPUDef, but this won't work in case the definition of the CPU model in QEMU contains more features than what we have in cpu_map.xml. We need to count with the usability blockers we got from QEMU and explicitly disable all of them to make the computed virCPUDef usable. https://bugzilla.redhat.com/show_bug.cgi?id=1464832 Jiri Denemark (23): util: Introduce virStringListCopy conf: Add usability blockers to virDomainCapsCPUModel qemu: Store CPU usability blockers in caps cache qemu: Parse unavailable features for CPU models cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs cpu: Drop unused parameter from cpuDecode cpu: Return model from virCPUModelIsAllowed cpu_x86: Move x86FeatureFind* to avoid forward prototypes cpu_x86: Disable blockers from unusable CPU models cputest: Replace json bool with enum cputest: Avoid calling json_reformat in cpu-parse.sh cputest: Print correct feature in virCPUUpdateLive test cputest: Test CPU usability blockers cputest: Separate QEMUCaps creation from cpuTestCPUIDJson build: Export virCPUModelIsAllowed private API cputest: Use CPU models from QEMU when available cputest: Add query-cpu-definitions reply for Core-i5-2540M cputest: Add CPUID data for Intel(R) Xeon(R) CPU E7-4830 cputest: Add query-cpu-definitions reply for Xeon-E7-4830 cputest: Update Xeon-E3-1245 data cputest: Add query-cpu-definitions reply for Xeon-E3-1245 cputest: Update Core-i7-2600 data cputest: Make a crippled version of Core-i7-2600 src/conf/domain_capabilities.c | 30 +- src/conf/domain_capabilities.h | 7 +- src/cpu/cpu.c | 95 +- src/cpu/cpu.h | 31 +- src/cpu/cpu_arm.c | 3 +- src/cpu/cpu_ppc64.c | 14 +- src/cpu/cpu_x86.c | 108 +- src/libvirt_private.syms | 1 + src/libxl/libxl_capabilities.c | 2 +- src/libxl/libxl_driver.c | 2 +- src/qemu/qemu_capabilities.c | 123 +-- src/qemu/qemu_capabilities.h | 6 +- src/qemu/qemu_capspriv.h | 5 + src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_monitor.c | 2 + src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 26 +- src/qemu/qemu_process.c | 9 +- src/test/test_driver.c | 2 +- src/util/virstring.c | 37 + src/util/virstring.h | 3 + tests/cputest.c | 324 ++++-- tests/cputestdata/cpu-cpuid.py | 26 +- tests/cputestdata/cpu-gather.sh | 1 + tests/cputestdata/cpu-parse.sh | 2 +- tests/cputestdata/cpu-reformat.py | 9 + tests/cputestdata/x86_64-cpuid-Core-i5-2540M.json | 362 +++++++ .../x86_64-cpuid-Core-i7-2600-disabled.xml | 1 - .../x86_64-cpuid-Core-i7-2600-enabled.xml | 1 + .../cputestdata/x86_64-cpuid-Core-i7-2600-json.xml | 1 + ...x86_64-cpuid-Core-i7-2600-xsaveopt-disabled.xml | 6 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-enabled.xml | 8 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-guest.xml | 25 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-host.xml | 25 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-json.xml | 11 + .../x86_64-cpuid-Core-i7-2600-xsaveopt.json | 615 +++++++++++ .../x86_64-cpuid-Core-i7-2600-xsaveopt.xml | 33 + tests/cputestdata/x86_64-cpuid-Core-i7-2600.json | 496 ++++++++- tests/cputestdata/x86_64-cpuid-Core-i7-2600.xml | 6 +- .../x86_64-cpuid-Xeon-E3-1245-disabled.xml | 1 - .../x86_64-cpuid-Xeon-E3-1245-enabled.xml | 2 +- .../cputestdata/x86_64-cpuid-Xeon-E3-1245-json.xml | 1 + tests/cputestdata/x86_64-cpuid-Xeon-E3-1245.json | 712 +++++++++---- tests/cputestdata/x86_64-cpuid-Xeon-E3-1245.xml | 7 +- .../x86_64-cpuid-Xeon-E7-4830-disabled.xml | 5 + .../x86_64-cpuid-Xeon-E7-4830-enabled.xml | 8 + .../x86_64-cpuid-Xeon-E7-4830-guest.xml | 28 + .../cputestdata/x86_64-cpuid-Xeon-E7-4830-host.xml | 29 + .../cputestdata/x86_64-cpuid-Xeon-E7-4830-json.xml | 14 + tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.json | 657 ++++++++++++ tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.xml | 30 + tests/domaincapstest.c | 6 +- tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1102 ++++++++++++++++++-- tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 236 ++++- tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 154 ++- tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 154 ++- 56 files changed, 4927 insertions(+), 680 deletions(-) create mode 100755 tests/cputestdata/cpu-reformat.py create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt.json create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.xml -- 2.14.2

3 66

[PATCH v2 00/21] qom: introduce property flags to track external user input
by Zhao Liu 13 Aug '26

13 Aug '26

Hi, This is the v2 trying to introduce property flags to detect user's property setting (from CLI/QMP/HMP). I dropped RFC tag since previous RFC v1 [1]. Though this work the follow-up of v2.6 & v2.7 machines' removal [2], now it is decoupled from [2] totally since v2 doesn't detect compat property and only focuses on external user setting, so this series is based on master branch at the commit 28a6ca268c2c ("Merge tag 'single- binary-20260203' of https://github.com/philmd/qemu into staging"). And you can also find the code here: https://gitlab.com/zhao.liu/qemu/-/tree/prop-flags-v2.3-02-08-2026 This series introduces 3 property flags: * USER_SET: Any external user property setting (from CLI/HMP/QMP) is marked as USER_SET. * DEPRECATED: Once a property is marked as DEPRECATED, any external user property setting will trigger a warning. * INTERNAL: Once a property is marked as INTERNAL, any external user property setting will cause an error. More details or document for these 3 flags, you can refer patch 7. Compared with RFC v1, v2 mainly: * introduce USER_SET property flag to identify all user's setting. - patch 7 for document. * construct DEPRECATED & INTERNAL flag on USER_SET. - patch 7 for document. * cover more comprehensive user set cases. - patch 8-13. * provide examples about new flags (USER_SET/DEPRECATED/INTELNAL). - patch 15/16/17 are examples for DEPRECATED flag. - patch 18 is the example for INTERNAL flag. - patch 20 is the example for USER_SET flag. I think v2 should now cover "nearly" all cases (patch 8-13) where users set properties: one approach is to trace the call chain of object_property_set(). Even if there are cases that were missed, they can be easily addressed based on this series: object_property_set(obj, ...); /* Insert this call after object_property_set(). */ object_property_set_flags(obj, ..., OBJ_PROP_FLAG_USER_SET, ...); [1]: RFC v1: https://lore.kernel.org/qemu-devel/20251202170502.3228625-1-zhao1.liu@intel… [2]: hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines https://lore.kernel.org/qemu-devel/20260108033051.777361-1-zhao1.liu@intel.… Thanks and Best Regards, Zhao --- Zhao Liu (21): qom/object: use BIT macro for ObjectPropertyFlags qom/object: cache ObjectPropertyFlags in ObjectProperty qom/object: factor out object_class_property_try_add() qom/object: add flags argument in object_{class_}property_try_add() qom/object: rename object_{class_}property_try_add() to object_{class_}property_add_full() qom/object: add helpers to set/get/clear property flags qom/object: introduce user interaction flags for properties qom/object: add from_user argument in object_property_parse() qom/object: mark global property set from CLI as USER_SET qom/qom-hmp-cmd: mark properties set from HMP (non-JSON) "qom-set" as USER_SET qom/qom-qmp-cmd: mark properties set from QMP/HMP (JSON) "qom-set" as USER_SET qom/object_interfaces: mark properties set from qdict & keyval as USER_SET system/vl: mark property set in object_parse_property_opt() as USER_SET hw/core/qdev-properties: allow qdev properties accept flags target/i386: deprecate fill-mtrr-mask property target/i386: deprecate cpuid-0xb property hw/intc/ioapic: deprecate version property target/i386: mark x-consistent-cache property as internal-only target/i386: remove redundant validation for lbr-fmt property target/i386: detect user provided lbr-fmt via property flag hw/core/qdev-properties: support valid default value for DEFINE_PROP_UINT64_CHECKMASK docs/about/deprecated.rst | 31 +++++ hw/core/qdev-properties.c | 29 ++-- hw/i386/sgx.c | 2 +- hw/intc/ioapic.c | 3 +- include/hw/core/qdev-properties.h | 38 +++--- include/qom/object.h | 215 +++++++++++++++++++++++++++--- qom/object.c | 177 ++++++++++++++++++++---- qom/object_interfaces.c | 5 + qom/qom-hmp-cmds.c | 2 +- qom/qom-qmp-cmds.c | 7 +- system/vl.c | 6 +- target/i386/cpu.c | 28 ++-- 12 files changed, 448 insertions(+), 95 deletions(-) -- 2.34.1

10 45

[PATCH] util: Fix secondary bus reset check for multi-root PCI systems
by ehanoc 23 Apr '26

23 Apr '26

The virPCIDeviceReset() function was using a hardcoded check for bus != 0 to determine if a device is on a root bus before attempting a secondary bus reset. This breaks on multi-root systems like Intel Arrow Lake where devices can be on non-zero root buses (e.g., Bus 0x80 for the PCH root complex). Update the logic to use virPCIDeviceIsOnRootBus() which detects root bus attachment via sysfs topology, making it work correctly on any PCI-compliant system regardless of bus numbers. This ensures secondary bus reset is never attempted on ANY root bus (0x00, 0x80, etc.), only on devices behind PCI bridges where it's safe. Signed-off-by: Bruno Martins <ehanoc(a)protonmail.com> --- src/util/virpci.c | 106 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 99 insertions(+), 7 deletions(-) diff --git a/src/util/virpci.c b/src/util/virpci.c index 2348a98003..f2ce24e6aa 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -1081,6 +1081,81 @@ virPCIDeviceInit(virPCIDevice *dev, int cfgfd) return 0; } +/* + * Check if a PCI device is directly attached to a root bus (no parent bridge). + * + * Modern systems like Intel Arrow Lake (Core Ultra 200) can have multiple + * root buses (e.g., bus 0x00 for CPU devices and bus 0x80 for PCH devices). + * We detect root bus attachment by examining the sysfs topology: a device + * is on a root bus if its sysfs path is a direct child of a pciXXXX:YY + * directory (e.g., /sys/devices/pci0000:80/0000:80:14.0). + * + * Returns 1 if on root bus, 0 if not, -1 on error. + */ +static int +virPCIDeviceIsOnRootBus(virPCIDevice *dev) +{ + unsigned int domain, bus; + g_autofree char *devPath = NULL; + g_autofree char *realPath = NULL; + g_autofree char *parentDir = NULL; + const char *parentName; + + /* Get the sysfs symlink path for this device */ + devPath = g_strdup_printf(PCI_SYSFS "devices/%s", dev->name); + + /* Resolve the symlink to get the real path in /sys/devices/... */ + if (virFileResolveLink(devPath, &realPath) < 0) { + VIR_DEBUG("%s %s: failed to resolve sysfs path %s", + dev->id, dev->name, devPath); + return -1; + } + + parentDir = g_path_get_dirname(realPath); + if (!parentDir) + return -1; + + parentName = strrchr(parentDir, '/'); + if (!parentName) + return -1; + parentName++; // skip the '/' + + /* + * Detect root bus by parsing the parent directory name using sscanf. + * + * PCI root buses in sysfs follow the naming convention: + * pci<domain>:<bus> + * + * - <domain>: number (0000-ffff, hex) + * - <bus>: number within the domain (00-ff, hex) + * + * This format is defined in: + * https://www.kernel.org/doc/html/latest/PCI/sysfs-pci.html + * + * Examples from Intel Arrow Lake systems: + * - pci0000:00 (CPU root bus) + * - pci0000:80 (PCH root bus - the problematic case on Arrow Lake) + * + * sscanf pattern "pci%x:%x" matches: + * - "pci" : literal prefix + * - "%x" : hex domain (stops at ':') + * - ":" : literal separator + * - "%x" : hex bus (must reach end of string) + * + * Returns 2 if both domain and bus were successfully parsed, + * confirming the device is a direct child of a root bus. + */ + if (sscanf(parentName, "pci%x:%x", &domain, &bus) == 2) { + VIR_DEBUG("%s %s: device is on root bus (parent=%s)", + dev->id, dev->name, parentName); + return 1; + } + + VIR_DEBUG("%s %s: device is not on root bus (parent=%s)", + dev->id, dev->name, parentName); + return 0; +} + int virPCIDeviceReset(virPCIDevice *dev, virPCIDeviceList *activeDevs, @@ -1146,9 +1221,17 @@ virPCIDeviceReset(virPCIDevice *dev, if (dev->has_pm_reset) ret = virPCIDeviceTryPowerManagementReset(dev, fd); - /* Bus reset is not an option with the root bus */ - if (ret < 0 && dev->address.bus != 0) - ret = virPCIDeviceTrySecondaryBusReset(dev, fd, inactiveDevs); + /* Bus reset is not an option with the root bus. On multi-root + * systems like Intel Arrow Lake, root buses can be non-zero (e.g., 0x80), + * so we use sysfs topology detection instead of checking bus == 0. + */ + if (ret < 0) { + int onRootBus = virPCIDeviceIsOnRootBus(dev); + if (onRootBus < 0) + goto cleanup; + if (!onRootBus) + ret = virPCIDeviceTrySecondaryBusReset(dev, fd, inactiveDevs); + } if (ret < 0) { virErrorPtr err = virGetLastError(); @@ -2531,15 +2614,24 @@ static int virPCIDeviceIsBehindSwitchLackingACS(virPCIDevice *dev) { g_autoptr(virPCIDevice) parent = NULL; + int onRootBus; if (virPCIDeviceGetParent(dev, &parent) < 0) return -1; if (!parent) { - /* if we have no parent, and this is the root bus, ACS doesn't come - * into play since devices on the root bus can't P2P without going - * through the root IOMMU. + /* If we have no parent bridge, check if the device is directly + * attached to a root bus. Systems like Intel Arrow Lake can have + * multiple root buses (e.g., 0x00 and 0x80), so we can't just + * check for bus == 0. Instead, use sysfs topology to detect + * root bus attachment. + * + * ACS doesn't come into play for devices on root buses since + * they can't P2P without going through the root IOMMU. */ - if (dev->address.bus == 0) { + onRootBus = virPCIDeviceIsOnRootBus(dev); + if (onRootBus < 0) + return -1; + if (onRootBus) { return 0; } else { virReportError(VIR_ERR_INTERNAL_ERROR, -- 2.47.3

5 8

[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] qemu: migration: Call hook script on source host at migration start
by Guy Godfroy 07 Apr '26

07 Apr '26

Currently, the qemu hook script with the "migrate" operation is only called on the destination host at the beginning of incoming migration. This makes it impossible for the source host to prepare for migration, for example to change storage locks from exclusive to shared mode when using shared LVM storage with lvmlockd. Add a hook call on the source host at the beginning of outgoing migration. The hook is called with "source" as the extra argument to distinguish it from the destination hook which uses "-". The same change is also applied to the libxl driver for consistency. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/37 Signed-off-by: Guy Godfroy <guy.godfroy(a)gugod.fr> --- docs/hooks.rst | 36 ++++++++++++++++++++++++++++++++---- src/libxl/libxl_migration.c | 17 +++++++++++++++++ src/qemu/qemu_migration.c | 17 +++++++++++++++++ 3 files changed, 66 insertions(+), 4 deletions(-) diff --git a/docs/hooks.rst b/docs/hooks.rst index e1745b8cc7..4c7cac56ba 100644 --- a/docs/hooks.rst +++ b/docs/hooks.rst @@ -244,7 +244,7 @@ operation. There is no specific operation to indicate a "restart" is occurring. - :since:`Since 0.9.11`, the qemu hook script is also called at the beginning - of incoming migration. It is called as: + of incoming migration on the **destination** host. It is called as: :: @@ -257,6 +257,18 @@ operation. There is no specific operation to indicate a "restart" is occurring. is not valid, incoming migration will be canceled. This hook may be used, e.g., to change location of disk images for incoming domains. +- :since:`Since 12.1.0`, the qemu hook script is also called at the beginning + of outgoing migration on the **source** host. It is called as: + + :: + + /etc/libvirt/hooks/qemu guest_name migrate begin source + + with domain XML sent to standard input of the script. Unlike the destination + hook, this script does not act as a filter and any output is ignored. If the + script returns failure, the migration will be canceled. This hook may be used, + e.g., to change storage lock mode from exclusive to shared before migration. + - :since:`Since 1.2.9`, the qemu hook script is also called when restoring a saved image either via the API or automatically when restoring a managed save machine. It is called as: @@ -417,7 +429,7 @@ operation. There is no specific operation to indicate a "restart" is occurring. /etc/libvirt/hooks/libxl guest_name release end - - :since:`Since 2.1.0`, the libxl hook script is also called at the beginning - of incoming migration. It is called as: + of incoming migration on the **destination** host. It is called as: :: @@ -430,6 +442,18 @@ operation. There is no specific operation to indicate a "restart" is occurring. is not valid, incoming migration will be canceled. This hook may be used, e.g., to change location of disk images for incoming domains. +- :since:`Since 12.1.0`, the libxl hook script is also called at the beginning + of outgoing migration on the **source** host. It is called as: + + :: + + /etc/libvirt/hooks/libxl guest_name migrate begin source + + with domain XML sent to standard input of the script. Unlike the destination + hook, this script does not act as a filter and any output is ignored. If the + script returns failure, the migration will be canceled. This hook may be used, + e.g., to change storage lock mode from exclusive to shared before migration. + - :since:`Since 6.5.0`, you can also place several hook scripts in the directory ``/etc/libvirt/hooks/libxl.d/``. They are executed in alphabetical order after main script. In this case each script also acts as filter and can @@ -566,10 +590,14 @@ Migration of a QEMU guest involves running hook scripts on both the source and destination hosts: #. At the beginning of the migration, the *qemu* hook script on the - **destination** host is executed with the "migrate" operation. + **source** host is executed with the "migrate" operation and "source" + as the extra argument (:since:`since 12.1.0`). This allows the source + host to prepare for migration, e.g., changing storage locks. +#. Then, the *qemu* hook script on the **destination** host is executed + with the "migrate" operation. #. Before QEMU process is spawned, the two operations ("prepare" and "start") called for domain start are executed on **destination** host. -#. If both of these hook script executions exit successfully (exit status 0), +#. If all of these hook script executions exit successfully (exit status 0), the migration continues. Any other exit code indicates failure, and the migration is aborted. #. The QEMU guest is then migrated to the destination host. diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c index f5dee7627b..76f3c7ceb7 100644 --- a/src/libxl/libxl_migration.c +++ b/src/libxl/libxl_migration.c @@ -411,6 +411,23 @@ libxlDomainMigrationSrcBegin(virConnectPtr conn, if (!libxlDomainMigrationIsAllowed(def)) goto endjob; + /* Call hook to allow source host to prepare for migration */ + if (virHookPresent(VIR_HOOK_DRIVER_LIBXL)) { + g_autofree char *hookxml = NULL; + int hookret; + + if (!(hookxml = virDomainDefFormat(def, driver->xmlopt, + VIR_DOMAIN_DEF_FORMAT_SECURE))) + goto endjob; + + hookret = virHookCall(VIR_HOOK_DRIVER_LIBXL, def->name, + VIR_HOOK_LIBXL_OP_MIGRATE, VIR_HOOK_SUBOP_BEGIN, + "source", hookxml, NULL); + + if (hookret < 0) + goto endjob; + } + xml = virDomainDefFormat(def, driver->xmlopt, VIR_DOMAIN_DEF_FORMAT_SECURE); /* Valid xml means success! EndJob in the confirm phase */ if (xml) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 6dd022163b..60e370319c 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2791,6 +2791,23 @@ qemuMigrationSrcBeginPhase(virQEMUDriver *driver, if (!qemuMigrationSrcIsAllowed(vm, true, vm->job->asyncJob, flags)) return NULL; + /* Call hook to allow source host to prepare for migration */ + if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) { + g_autofree char *xml = NULL; + int hookret; + + if (!(xml = qemuDomainDefFormatLive(driver, priv->qemuCaps, vm->def, + priv->origCPU, false, true))) + return NULL; + + hookret = virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, + VIR_HOOK_QEMU_OP_MIGRATE, VIR_HOOK_SUBOP_BEGIN, + "source", xml, NULL); + + if (hookret < 0) + return NULL; + } + if (!(flags & (VIR_MIGRATE_UNSAFE | VIR_MIGRATE_OFFLINE)) && !qemuMigrationSrcIsSafe(vm, migrate_disks, flags)) return NULL; -- 2.34.1

4 18

[PATCH v5 0/3] nwfilter: add nwfilter nftables driver
by Dion Bosschieter 30 Mar '26

30 Mar '26

This series aims to implement nftables as a backend driver for the nwfilter feature. The idea is that it will replace the ebiptables driver and provide an easy way for users to switch from one driver to another. The 1st patch introduces the new nwfilter driver. After which nwfilter allows users to choose it in the 2nd patch. The last patch introduces unit testing of the new nftables driver. - Implemented very basic nwfilter.conf reading and choosing a nwfilter driver based on the name of the drivers (nftables/ebiptables). Defaults to the nftables driver, based on the firewall_backend_priority meson option, following the bridge driver logic. - Resolves issue https://gitlab.com/libvirt/libvirt/-/issues/603 benchmarks showed that the amount of iifname jumps for each interface with is the cause for this. Switched the nftables driver towards a vmap (verdict map) so we can have 1 rule that jumps to the correct root input/output chain per interface. Which improves throughput as when the number of interface check and jump rules increases the throughput decreases. The issue describes the interface matching works using the interface name and the majority of the effort is the strncpy, this commit also switches nftables to an interface_index compare instead. However, just using the interface_index is not enough, the amount of oif and iif jump rules causes quite a performance issue, the vmap instead solves this. - Split rules into separate tables: "libvirt-nwfilter-ethernet" and "libvirt-nwfilter-other" to preserve existing firewall behavior. - Reworked chain logic for clarity with root -input/-output chains per interface. input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). - Stuck with prerouting and postrouting as hooks for input / output on the -ethernet and -other table. This makes it easier to merge the tables in the future. Saving management of two tables and decreasing the amount of tables a packet sees. Currently ebtables filtering happens via PREROUTING and POSTROUTING hooks, while ip/ip6tables filtering happens in the output/forward hooks. - Stuck with 2 tables for compatibility reasons with eb iptables, unifying into 1 table will break users firewall definitions, which depend on being able to do accepts on ethernet rules (which currently get defined via ebtables) and additional filtering via the ip rules (which currently get defined via ip(6)tables). The nwfilter_nftables_driver keeps splitting the ethernet and non ethernet (other) rules in seperate tables "libvirt-nwfilter-ethernet" and "libvirt-nwfilter-other". - Rewrote chain logic, so it is easier to understand, input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). -ethernet and -other table follow the same style and hook in the same way. - Simplified conntrack handling: rules with accept+conntrack are duplicated to the opposite chain for symmetric behavior, to support the existing ebiptables logic. - Firewall updates continue use tmp names for atomic replacement. Unsupported nwfilter features (for now): - STP filtering - Gratuitous ARP filtering - IPSets (potential future support via nft sets) - Reject due to filtering in pre/postrouting, using drop instead of reject, copying logic from existing ebiptables ebtables actions Future improvements: - Use `nft -f` for atomic rule application. - Optional single-table mode via nwfilter.conf. - Optimize boot phase with chain hash comparison. --- Changes in v5: - Fix rarp support via nft raw payload expression Changes in v4: - Fix rarp nft commands "arp saddr ether" "arp daddr ether" - Filter chain creation, don't create unnecessary chains - Apply danpb seperate argument suggestion - Fix table not existing errors in drop all rules - Fix table not existing errors in apply basic rules Changes in v3: - Renamed -other to -inet - Renamed - to _ in table names - Updated rule / chain sorting on ethernet table to to copy ebtables logic - Fix possible broken revert path - Fix remove rules not working in some cases, EBUSY - Shared functions camel case commit - Rename config option - Add extra config params, enable_trace, enable_counters This required passing the config struct to the ebip/nft nwfilter drivers - Add extra augeaus files Changes in v2: - Rename {ebip,nf}tables specific test files in 1 directory instead of seperating them in different directories. - Added default nwfilter.conf file in git, documented including augeas files - Replaced hardcoding of default driver based on existing firewall_backend_priority meson option. - Added nwfilter_driver_conf.{h,c} for configuration handling, to match the common pattern used in other drivers. Dion Bosschieter (3): nwfilter: add nwfilter nftables driver nwfilter: allow use of nftables nwfilter driver via nwfilter.conf nwfilter: add unit tests and test data for nwfilter nftables driver libvirt.spec.in | 7 + po/POTFILES | 2 + src/conf/virnwfilterobj.h | 20 - src/nwfilter/libvirtd_nwfilter.aug | 45 + src/nwfilter/meson.build | 38 + src/nwfilter/nwfilter.conf.in | 50 + src/nwfilter/nwfilter_driver.c | 66 +- src/nwfilter/nwfilter_driver_conf.c | 214 + src/nwfilter/nwfilter_driver_conf.h | 69 + src/nwfilter/nwfilter_ebiptables_driver.c | 4 +- src/nwfilter/nwfilter_ebiptables_driver.h | 2 +- src/nwfilter/nwfilter_gentech_driver.c | 65 +- src/nwfilter/nwfilter_gentech_driver.h | 5 +- src/nwfilter/nwfilter_nftables_driver.c | 2668 ++++++++++++ src/nwfilter/nwfilter_nftables_driver.h | 28 + src/nwfilter/nwfilter_tech_driver.h | 3 +- src/nwfilter/test_libvirtd_nwfilter.aug.in | 7 + tests/meson.build | 2 + tests/nwfilternftablestest.c | 426 ++ .../ah-ipv6-linux.nftables.args | 310 ++ .../ah-linux.nftables.args | 304 ++ .../all-ipv6-linux.nftables.args | 292 ++ .../all-linux.nftables.args | 286 ++ .../arp-linux.nftables.args | 231 + .../nwfilterxml2firewalldata/arp.nftables.xml | 27 + .../comment-linux.nftables.args | 510 +++ .../conntrack-linux.nftables.args | 198 + .../esp-ipv6-linux.nftables.args | 310 ++ .../esp-linux.nftables.args | 304 ++ .../example-1-linux.nftables.args | 268 ++ .../example-2-linux.nftables.args | 352 ++ .../hex-data-linux.nftables.args | 384 ++ .../icmp-direction-linux.nftables.args | 238 ++ .../icmp-direction2-linux.nftables.args | 238 ++ .../icmp-direction3-linux.nftables.args | 184 + .../icmp-linux.nftables.args | 256 ++ .../icmpv6-linux.nftables.args | 328 ++ .../igmp-linux.nftables.args | 304 ++ .../ip-linux.nftables.args | 205 + .../ipt-no-macspoof-linux.nftables.args | 172 + .../ipv6-linux.nftables.args | 511 +++ .../iter1-linux.nftables.args | 304 ++ .../iter2-linux.nftables.args | 3760 +++++++++++++++++ .../iter3-linux.nftables.args | 430 ++ .../mac-linux.nftables.args | 184 + .../rarp-linux.nftables.args | 215 + .../sctp-ipv6-linux.nftables.args | 328 ++ .../sctp-linux.nftables.args | 328 ++ .../target-linux.nftables.args | 466 ++ .../target2-linux.nftables.args | 322 ++ .../tcp-ipv6-linux.nftables.args | 328 ++ .../tcp-linux.nftables.args | 476 +++ .../udp-ipv6-linux.nftables.args | 328 ++ .../udp-linux.nftables.args | 328 ++ .../udplite-ipv6-linux.nftables.args | 310 ++ .../udplite-linux.nftables.args | 304 ++ .../vlan-linux.nftables.args | 271 ++ .../ah-ipv6-linux.args | 304 ++ .../nwfilterxml2nftfirewalldata/ah-linux.args | 298 ++ .../all-ipv6-linux.args | 286 ++ .../all-linux.args | 280 ++ .../arp-linux.args | 215 + tests/nwfilterxml2nftfirewalldata/arp.xml | 27 + .../comment-linux.args | 483 +++ .../conntrack-linux.args | 198 + .../esp-ipv6-linux.args | 304 ++ .../esp-linux.args | 298 ++ .../example-1-linux.args | 266 ++ .../example-2-linux.args | 348 ++ .../hex-data-linux.args | 357 ++ .../icmp-direction-linux.args | 238 ++ .../icmp-direction2-linux.args | 238 ++ .../icmp-direction3-linux.args | 184 + .../icmp-linux.args | 252 ++ .../icmpv6-linux.args | 322 ++ .../igmp-linux.args | 298 ++ .../nwfilterxml2nftfirewalldata/ip-linux.args | 198 + .../ipt-no-macspoof-linux.args | 169 + .../ipv6-linux.args | 474 +++ .../iter1-linux.args | 298 ++ .../iter2-linux.args | 3598 ++++++++++++++++ .../iter3-linux.args | 418 ++ .../mac-linux.args | 180 + .../rarp-linux.args | 215 + .../sctp-ipv6-linux.args | 314 ++ .../sctp-linux.args | 314 ++ .../target-linux.args | 452 ++ .../target2-linux.args | 316 ++ .../tcp-ipv6-linux.args | 314 ++ .../tcp-linux.args | 468 ++ .../udp-ipv6-linux.args | 314 ++ .../udp-linux.args | 314 ++ .../udplite-ipv6-linux.args | 304 ++ .../udplite-linux.args | 298 ++ .../vlan-linux.args | 264 ++ tests/nwfilterxml2nftfirewalltest.c | 438 ++ 96 files changed, 33369 insertions(+), 102 deletions(-) create mode 100644 src/nwfilter/libvirtd_nwfilter.aug create mode 100644 src/nwfilter/nwfilter.conf.in create mode 100644 src/nwfilter/nwfilter_driver_conf.c create mode 100644 src/nwfilter/nwfilter_driver_conf.h create mode 100644 src/nwfilter/nwfilter_nftables_driver.c create mode 100644 src/nwfilter/nwfilter_nftables_driver.h create mode 100644 src/nwfilter/test_libvirtd_nwfilter.aug.in create mode 100644 tests/nwfilternftablestest.c create mode 100755 tests/nwfilterxml2firewalldata/ah-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ah-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/arp-linux.nftables.args create mode 100644 tests/nwfilterxml2firewalldata/arp.nftables.xml create mode 100755 tests/nwfilterxml2firewalldata/comment-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/conntrack-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/hex-data-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmpv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/igmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ip-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipt-no-macspoof-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/mac-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/rarp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/vlan-linux.nftables.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ah-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ah-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/all-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/all-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/arp-linux.args create mode 100644 tests/nwfilterxml2nftfirewalldata/arp.xml create mode 100755 tests/nwfilterxml2nftfirewalldata/comment-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/conntrack-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/esp-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/esp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/example-1-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/example-2-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/hex-data-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmp-direction-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmp-direction2-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmp-direction3-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmpv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/igmp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ip-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ipt-no-macspoof-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/iter1-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/iter2-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/iter3-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/mac-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/rarp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/sctp-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/sctp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/target-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/target2-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/tcp-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/tcp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/udp-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/udp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/udplite-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/udplite-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/vlan-linux.args create mode 100644 tests/nwfilterxml2nftfirewalltest.c -- 2.43.0

2 10

[PATCH v6 0/6] cover: RFE libvirt secret encryption on disk
by Arun Menon 30 Mar '26

30 Mar '26

Libvirt secrets are stored unencrypted on the disk. With this series we want to start encrypting the secrets. 1. Introduce the GnuTLS decryption wrapper functions that work exact opposite to the encryption wrappers. 2. Add a new service called virt-secrets-init-encryption, that is linked to the virtsecretd 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. 6. Add documentation. 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 v6: - changes to use obj->secretValueFile as base - does local suffix lookups - refactors code so that the base64 encoding is in common code paths - moves local variable declaration inside blocks using them - refactors loader to use virFileReadAll instead of open-coding - fixes virSecretObjDeleteData to not rely on the actual filename Changes in v5: - Fix the bug of updating old secrets, prior to 12.1.0. Old secrets, when updated, now are stored with the latest encryption scheme if encryption is on. - Remove any logic in setting the secretValueFile in virSecretObjListAdd. Move it to virSecretLoadValue and virSecretObjSetValue. - Change urandom to random. Change default permission bits to 0077. - Update the documentation. Changes in v4: - Fix the regression of loading unencrypted secrets after an upgrade. Previously the .base64 unencrypted secrets were not being loaded. - Add documentation on encrypted secrets. 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 (6): util: Add support for GnuTLS decryption secret: Set up default encryption secret key for the virtsecretd service secret: Add secret.conf configuration file and parse it secret: Rename virSecretObj structure attribute from base64File to secretValueFile secret: Add functionality to load and save secrets in encrypted format docs: secret: Add documentation of secret encryption feature docs/drvsecret.rst | 4 + docs/meson.build | 1 + docs/secretencryption.rst | 105 +++++++++ include/libvirt/virterror.h | 1 + libvirt.spec.in | 8 + po/POTFILES | 1 + src/conf/virsecretobj.c | 210 +++++++++++++----- src/conf/virsecretobj.h | 14 +- src/libvirt_private.syms | 1 + src/meson.build | 1 + src/remote/libvirtd.service.in | 4 + src/secret/libvirt_secrets.aug | 40 ++++ src/secret/meson.build | 32 +++ src/secret/secret.conf.in | 14 ++ src/secret/secret_config.c | 179 +++++++++++++++ src/secret/secret_config.h | 40 ++++ src/secret/secret_driver.c | 29 ++- src/secret/test_libvirt_secrets.aug.in | 6 + .../virt-secret-init-encryption.service.in | 8 + src/secret/virtsecretd.service.extra.in | 8 + src/util/vircrypto.c | 126 ++++++++++- src/util/vircrypto.h | 8 + src/util/virerror.c | 3 + tests/vircryptotest.c | 65 ++++++ 24 files changed, 840 insertions(+), 68 deletions(-) create mode 100644 docs/secretencryption.rst 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

4 15

[RFC] Reintroducing customisable hotplug timeouts
by Akash Kulhalli 30 Mar '26

30 Mar '26

I'd like to resurface an earlier proposal [1] to make the unplug timeout user-configurable. With production guests running sustained, non-trivial workloads, we find that hot(un)plug operations regularly takes longer than the current default of 5s. However, the inability to easily configure this timeout means that in the worst case a recompilation with appropriate values set is required for each deployment, which is cumbersome to maintain and patch. The previous proposal [1] also initially made the timeout configurable, however that was specifically for the ppc64 architecture. Therefore, imposing this change for an entire architecture made sense, since it was a universal requirement for that platform. With deployment environments as diverse and varied as x86, having a single, inconfigurable value does not make as much sense now. For x86, such a change is not ideal since the desired timeout value depends very heavily on the deployment environment in use - if it is being performed by a human anything more than 10s is an undesirable user experience [2], as pointed out in the original discussion. However, more relaxed timeout values (e.g. 15-20s) can be more acceptable if the operations are background/ not directly user-facing. It is in these cases where the ability to change the timeout more easily becomes more desirable. To prevent misconfiguration, while maintaining the same out-of-box experience for existing users, I'd also like to propose the following- 1. As mentioned in the original proposal [1], the timeout cannot be set to a value lower than the default timeout of 5s; in these cases a warning will be emitted and the timeout will be reset to the default value. 2. Including an upper cap would also be desirable, in my opinion - any API consumer should not wait endlessly for an async operation to finish. 3. This configuration option will only be described in qemu.conf, not imposed - the out-of-box experience will remain unchanged at the current default (5s) for everyone who does not wish to tweak/is unaware of this value. An administrator who knowingly changes these values is therefore not blindsided by any perceived "hangs" resulting from the use of an increased timeout window. Since this would be a clearly documented and explicitly opt-in behaviour, the benefits in the form of easy modification based on evolving operational needs would be quite significant. Given the varying nature of production environments and specific operational needs at scale, it would therefore be beneficial to reconsider the merits of the original proposal. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/TXYV… [2] https://www.nngroup.com/articles/response-times-3-important-limits/

4 12