October 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

[PATCH 0/1] nwfilter: add default accept to nftables subchains
by Dion Bosschieter 27 Oct '26

27 Oct '26

This patch aims to let the nwfilter nftables driver follow the nwfilter ebtables driver In ebtables a subchain was created with a default accept When converted to nftables, this resulted in an "accept" at the end of each subchain: chain O-v100562794-mac { ether daddr 52:54:00:a3:13:87 counter packets 9 bytes 1145 return ether daddr 33:33:00:00:00:00/16 counter packets 48 bytes 3712 return ether daddr ff:ff:ff:ff:ff:ff counter packets 22 bytes 924 return counter packets 3 bytes 384 drop >>>> counter packets 0 bytes 0 accept } In order to mimick this behavior we add an "accept" for each subchain by calling nftablesCreateSubChainAccept after having created all of the fw rules. Dion Bosschieter (1): nwfilter: add default accept to nftables subchains src/nwfilter/nwfilter_nftables_driver.c | 60 +++++++++++++++++-- .../stp-linux.nftables.args | 14 +++++ 2 files changed, 69 insertions(+), 5 deletions(-) -- 2.53.0

1 1

Entering freeze for libvirt-12.9.0
by Jiri Denemark 26 Oct '26

26 Oct '26

I have just tagged v12.9.0-rc1 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Jirka

1 0

[PATCH 0/2] internal.h: Fix VIR_MULTIPLY_ADD_IS_OVERFLOW() macro when @add is zero
by Michal Privoznik 26 Oct '26

26 Oct '26

Green pipeline: https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/2990090049 Michal Prívozník (2): utiltest: Add MultiplyAddIsOverflow test case internal.h: Fix VIR_MULTIPLY_ADD_IS_OVERFLOW() macro when @add is zero src/internal.h | 2 +- tests/utiltest.c | 40 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 41 insertions(+), 1 deletion(-) -- 2.56.0

2 4

[FOSDEM] Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2027
by Piotr Kliczewski 26 Oct '26

26 Oct '26

We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2027, to be hosted on January 30th (Saturday). This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We invite everyone involved in these fields to submit your proposals by November 23rd. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM, libvirt, shared storage, virtualized networking, cloud security, clustering and high availability, interfacing with multiple hypervisors, hyperconverged deployments and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 23rd of November Acceptance notifications: 1st of December Final schedule announcement: 7th of December Devroom: 30th of January (Saturday) Submit Your Proposal During submission [1] please make sure to select Virtualization and Cloud infrastructure from the Track list. Please provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, Piotr Kliczewski and Tal Nisan In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct Following the release of the updated code of conduct for FOSDEM[2], we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://fosdem.org/submit [2] https://fosdem.org/2027/practical/conduct/ <https://fosdem.org/2026/practical/conduct/>

1 0

[PATCH] esx: Avoid integer overflow in esxDomainGetInfo()
by Michal Privoznik 26 Oct '26

26 Oct '26

From: Michal Privoznik <mprivozn(a)redhat.com> The virDomainGetInfo() fills virDomainInfo structure for given domain. The struct contains memory and maxMem members (among others) to store current and maximum memory for the domain. Both members are of 'unsigned long' type. Now, inside the ESX driver's implementation (esxDomainGetInfo()) these values are stored in a variables of int64_t and int32_t, respectively. But since both values, as reported by hypervisor are in MiB, they are multiplied by 1024 because we report memory sizes in KiB. Well, for very large guests, and 32bit hosts, unsigned long might not be large enough to hold the value. Check for overflow and also in case of 'maxMem' (which is multiplied directly) specify the type of '1024' constant to ensure proper typecast before multiplication. Resolves: https://gitlab.com/libvirt/libvirt/-/work_items/937 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/esx/esx_driver.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c index 75bbd07750..daca30aeca 100644 --- a/src/esx/esx_driver.c +++ b/src/esx/esx_driver.c @@ -2088,7 +2088,16 @@ esxDomainGetInfo(virDomainPtr domain, virDomainInfoPtr info) goto cleanup; } - info->maxMem = dynamicProperty->val->int32 * 1024; /* Scale from megabyte to kilobyte */ + if (VIR_MULTIPLY_ADD_IS_OVERFLOW(ULONG_MAX, + dynamicProperty->val->int32, 1024, 0)) { + virReportError(VIR_ERR_OVERFLOW, + _("the maximum memory value too large: %1$llu"), + (unsigned long long) dynamicProperty->val->int32); + goto cleanup; + } + + /* Scale from megabyte to kilobyte */ + info->maxMem = dynamicProperty->val->int32 * 1024UL; } else if (STREQ(dynamicProperty->name, "config.hardware.numCPU")) { if (esxVI_AnyType_ExpectType(dynamicProperty->val, esxVI_Type_Int) < 0) { @@ -2105,8 +2114,16 @@ esxDomainGetInfo(virDomainPtr domain, virDomainInfoPtr info) memory_limit = dynamicProperty->val->int64; - if (memory_limit > 0) + if (memory_limit > 0) { + if (VIR_MULTIPLY_ADD_IS_OVERFLOW(ULONG_MAX, memory_limit, 1024, 0)) { + virReportError(VIR_ERR_OVERFLOW, + _("the current memory value too large: %1$llu"), + (unsigned long long) memory_limit); + goto cleanup; + } + memory_limit *= 1024; /* Scale from megabyte to kilobyte */ + } } else { VIR_WARN("Unexpected '%s' property", dynamicProperty->name); } -- 2.56.0

2 1

[PATCH v2] util: virusb: skip USB devices with an inaccessible device node
by Yaroslav Borbat 26 Oct '26

26 Oct '26

From: Yaroslav Borbat <yaroslav.752(a)gmail.com> Inside a container sysfs is usually mounted from the host and exposes all USB devices, while nodes under /dev/bus/usb/ only exist for devices passed into the container's mount namespace. virUSBDeviceSearch() enumerated devices from sysfs alone, so such a device was reported as present: a hostdev with startupPolicy='optional' was not dropped and the domain failed to start. Skip devices whose /dev node is inaccessible during enumeration. virUSBDeviceFind() now ignores them for optional hostdevs and reports an explicit "not accessible in the current mount namespace" error for mandatory ones. Extend the virusb test to cover both cases. Signed-off-by: Yaroslav Borbat <yaroslav.752(a)gmail.com> Resolves: https://gitlab.com/libvirt/libvirt/-/work_items/894 --- v2: - rebased onto current master (no functional changes) v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/202… (https://patchew.org/Libvirt/20260716213249.3163905-1-yaroslav.752@gmail.com/) Context: this was hit with libvirt running inside a container (deckhouse/virtualization). Container runtimes mount sysfs from the host, so /sys/bus/usb/devices/ lists every host USB device, while /dev/bus/usb/ only contains the nodes explicitly passed into the container. A self-contained Docker reproducer (no special hardware needed, uses the root hub at bus 1 / device 1) is in the issue above. src/util/virusb.c | 41 ++++++++++++++++++++++++++++++++++++----- tests/virusbmock.c | 33 ++++++++++++++++++++++++++++++++- tests/virusbtest.c | 38 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 106 insertions(+), 6 deletions(-) diff --git a/src/util/virusb.c b/src/util/virusb.c index 85ad3d58ce..1d31912971 100644 --- a/src/util/virusb.c +++ b/src/util/virusb.c @@ -120,7 +120,8 @@ virUSBDeviceSearch(unsigned int vendor, unsigned int devno, const char *port, const char *vroot, - unsigned int flags) + unsigned int flags, + char **inaccessiblePath) { g_autoptr(DIR) dir = NULL; bool found = false; @@ -198,6 +199,28 @@ virUSBDeviceSearch(unsigned int vendor, if (!usb) goto cleanup; + /* In containerized environments sysfs may expose USB devices + * from the host kernel while the corresponding device node + * under /dev/bus/usb/ is not present in the current mount + * namespace. Such a device cannot be used, so skip it here. + * Remember its path so that the caller can distinguish "no + * matching device at all" from "device present on the host but + * inaccessible in our mount namespace" when reporting errors. */ + if (virUSBDeviceGetPath(usb) && + !virFileExists(virUSBDeviceGetPath(usb))) { + VIR_DEBUG("USB device %03u:%03u found in sysfs but device " + "node '%s' is not accessible in the current mount " + "namespace, skipping", + found_bus, found_devno, + virUSBDeviceGetPath(usb)); + if (inaccessiblePath && !*inaccessiblePath) + *inaccessiblePath = g_strdup(virUSBDeviceGetPath(usb)); + g_clear_pointer(&usb, virUSBDeviceFree); + if (found) + break; + continue; + } + if (virUSBDeviceListAdd(list, &usb) < 0) goto cleanup; @@ -226,10 +249,11 @@ virUSBDeviceFind(unsigned int vendor, virUSBDeviceList **devices) { g_autoptr(virUSBDeviceList) list = NULL; + g_autofree char *inaccessiblePath = NULL; int count; if (!(list = virUSBDeviceSearch(vendor, product, bus, devno, port, - vroot, flags))) + vroot, flags, &inaccessiblePath))) return -1; count = list->count; @@ -240,9 +264,16 @@ virUSBDeviceFind(unsigned int vendor, return 0; } - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Did not find matching USB device: vid:%1$04x, pid:%2$04x, bus:%3$u, device:%4$u, port:%5$s"), - vendor, product, bus, devno, port ? port : ""); + if (inaccessiblePath) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("USB device vid:%1$04x, pid:%2$04x, bus:%3$u, device:%4$u, port:%5$s is present on the host but its device node '%6$s' is not accessible in the current mount namespace"), + vendor, product, bus, devno, port ? port : "", + inaccessiblePath); + } else { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Did not find matching USB device: vid:%1$04x, pid:%2$04x, bus:%3$u, device:%4$u, port:%5$s"), + vendor, product, bus, devno, port ? port : ""); + } return -1; } diff --git a/tests/virusbmock.c b/tests/virusbmock.c index c23bed4528..c67a0ba307 100644 --- a/tests/virusbmock.c +++ b/tests/virusbmock.c @@ -22,18 +22,27 @@ #include <sys/stat.h> #include <dirent.h> #include <dlfcn.h> +#include <errno.h> #include <fcntl.h> +#include <unistd.h> #include "virmock.h" #define USB_SYSFS "/sys/bus/usb" #define FAKE_USB_SYSFS "virusbtestdata/sys_bus_usb" +#define USB_DEVFS "/dev/bus/usb/" + +/* Device node of the test device that is present in the fake sysfs but is + * meant to be inaccessible in the current mount namespace (usb4, i.e. the + * root hub 1d6b:0003 on bus 4). See virusbtest.c. */ +#define INACCESSIBLE_USB_NODE USB_DEVFS "004/001" static int (*real_open)(const char *pathname, int flags, ...); #if WITH___OPEN_2 static int (*real___open_2)(const char *path, int flags); #endif static DIR *(*real_opendir)(const char *name); +static int (*real_access)(const char *path, int mode); static void init_syms(void) { @@ -49,6 +58,7 @@ static void init_syms(void) VIR_MOCK_REAL_INIT(__open_2); #endif VIR_MOCK_REAL_INIT(opendir); + VIR_MOCK_REAL_INIT(access); } static char *get_fake_path(const char *real_path) @@ -58,7 +68,7 @@ static char *get_fake_path(const char *real_path) if ((p = STRSKIP(real_path, USB_SYSFS))) path = g_strdup_printf("%s/%s/%s", abs_srcdir, FAKE_USB_SYSFS, p); - else if (!p) + else path = g_strdup(real_path); return path; @@ -75,6 +85,27 @@ DIR *opendir(const char *name) return real_opendir(path); } +int access(const char *path, int mode) +{ + init_syms(); + + /* virUSBDeviceSearch() checks whether the /dev/bus/usb node of a device + * found in sysfs is accessible. There are no such nodes in the test + * environment, so pretend every USB device node exists, except the one + * device that is meant to be inaccessible in the current mount namespace + * (as happens inside a container). This lets us exercise the code path + * without shipping empty device-node files. */ + if (STRPREFIX(path, USB_DEVFS)) { + if (STREQ(path, INACCESSIBLE_USB_NODE)) { + errno = ENOENT; + return -1; + } + return 0; + } + + return real_access(path, mode); +} + int open(const char *pathname, int flags, ...) { g_autofree char *path = NULL; diff --git a/tests/virusbtest.c b/tests/virusbtest.c index 12ac338df9..58ca769059 100644 --- a/tests/virusbtest.c +++ b/tests/virusbtest.c @@ -259,6 +259,40 @@ testUSBList(const void *opaque G_GNUC_UNUSED) } +/* usb4 (bus 4, device 1) is present in the fake sysfs, but the mock makes + * its /dev/bus/usb node inaccessible, i.e. the device is exposed by the host + * kernel but not accessible in our mount namespace (as happens inside a + * container). Such a device must be treated as absent: skipped for + * startupPolicy 'optional' (mandatory == false) and reported as an error + * otherwise. */ +static int +testDeviceFindInaccessible(const void *opaque G_GNUC_UNUSED) +{ + g_autoptr(virUSBDeviceList) devs = NULL; + int rv; + + rv = virUSBDeviceFind(0x1d6b, 0x0003, 4, 1, NULL, NULL, false, + USB_DEVICE_FIND_BY_DEVICE, &devs); + if (rv != 0 || devs) { + virReportError(VIR_ERR_INTERNAL_ERROR, + "optional inaccessible device: expected no match " + "(rv=0 and no device list), got rv=%d", rv); + return -1; + } + + rv = virUSBDeviceFind(0x1d6b, 0x0003, 4, 1, NULL, NULL, true, + USB_DEVICE_FIND_BY_DEVICE, &devs); + if (rv >= 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + "mandatory inaccessible device: expected failure, " + "but the device was reported as available"); + return -1; + } + + return 0; +} + + static int mymain(void) { @@ -336,6 +370,10 @@ mymain(void) if (virTestRun("USB List test", testUSBList, NULL) < 0) rv = -1; + if (virTestRun("USBDeviceFind inaccessible node", + testDeviceFindInaccessible, NULL) < 0) + rv = -1; + if (rv < 0) return EXIT_FAILURE; return EXIT_SUCCESS; base-commit: ad0aefa6c66599bae1ebd3eeace615e247735e71 -- 2.55.0

1 0

[PATCH] NEWS: document bhyve changes for 12.9.0
by Roman Bogorodskiy 26 Oct '26

26 Oct '26

Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- NEWS.rst | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index a30bc9bc7b..bba5c66dac 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,6 +17,37 @@ v12.9.0 (unreleased) * **New features** + * bhyve: support session mode + + The bhyve driver now supports the session mode: ``bhyve:///session``. + It requires bhyve monitor mode support, so at the time of writing it + is available to -CURRENT users only. + + * bhyve: support boot order configuration for disks + + The bhyve driver now supports boot order configuration for the + SATA and VirtIO disks with ``<boot order='..'/>``. Now it also + uses the QEMU-compatible ``fwcfg`` interface. + + * bhyve: TPM support + + The bhyve driver now supports TPM with an external emulator. + + * bhyve: implement ``virDomainReset()`` + + The bhyve driver now implements the ``virDomainReset()`` API + (accessible via ``virsh reset``). + + * FreeBSD: support isolated bridge ports + + libvirt on FreeBSD now supports isolated bridge ports such as:: + + <interface type='bridge'> + <source bridge='bridge0'/> + <model type='virtio'/> + <port isolated='yes'/> + </interface> + * **Improvements** * qemu: Emit UNDEFINED event when undefining source after migration @@ -28,6 +59,10 @@ v12.9.0 (unreleased) * **Bug fixes** + * bhyve: fix shutdown handling on arm64 + + Signal-based shutdown now correctly handles bhyve terminating directly + on arm64, preventing stopped domains from remaining reported as running. v12.8.0 (2026-10-01) ==================== -- 2.55.0

2 1

[PATCH] bhyve: fix shutdown handling on arm64
by Roman Bogorodskiy 23 Oct '26

23 Oct '26

The bhyve driver requests signal-based shutdown by sending a SIGTERM signal to the bhyve process. On amd64 bhyve handles this signal to start ACPI shutdown. On arm64 bhyve does not implement ACPI shutdown, so it does not implement a signal handler for SIGTERM and just terminates. These cases are seen differently in the monitor, and the latter case is not handled, which could result in stopped domain reported as running. Fix by handling both cases. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/bhyve/bhyve_monitor.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/bhyve/bhyve_monitor.c b/src/bhyve/bhyve_monitor.c index dab07ff95f..8e481b17aa 100644 --- a/src/bhyve/bhyve_monitor.c +++ b/src/bhyve/bhyve_monitor.c @@ -20,6 +20,7 @@ #include <config.h> +#include <signal.h> #include <sys/types.h> #include <sys/event.h> #include <sys/time.h> @@ -117,6 +118,7 @@ bhyveMonitorIO(int watch, int kq, int events G_GNUC_UNUSED, void *opaque) const char *name; struct kevent kev; int rc, status; + bool shutdownBySignal; if (watch != mon->watch || kq != mon->kq) { virReportError(VIR_ERR_INTERNAL_ERROR, @@ -153,13 +155,19 @@ bhyveMonitorIO(int watch, int kq, int events G_GNUC_UNUSED, void *opaque) name = vm->def->name; status = kev.data; + /* On amd64 SIGTERM triggers ACPI shutdown, and we see it as WIFEXITED(status). + * However, arm64 has no SIGTERM handler, so we see it as WIFSIGNALED(status). + */ + shutdownBySignal = WIFSIGNALED(status) && + WTERMSIG(status) == SIGTERM; + if (WIFSIGNALED(status) && WCOREDUMP(status)) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Guest %1$s got signal %2$d and crashed"), name, WTERMSIG(status)); virBhyveProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_CRASHED, false); - } else if (WIFEXITED(status)) { - if (WEXITSTATUS(status) == 0 || mon->reboot) { + } else if (WIFEXITED(status) || shutdownBySignal) { + if ((!shutdownBySignal && WEXITSTATUS(status) == 0) || mon->reboot) { /* 0 - reboot */ if (vm->def->onReboot == VIR_DOMAIN_LIFECYCLE_ACTION_DESTROY || vm->def->onReboot == VIR_DOMAIN_LIFECYCLE_ACTION_PRESERVE) { @@ -169,7 +177,7 @@ bhyveMonitorIO(int watch, int kq, int events G_GNUC_UNUSED, void *opaque) VIR_INFO("Guest %s rebooted; restarting domain.", name); virBhyveProcessRestart(driver, vm); } - } else if (WEXITSTATUS(status) < 3) { + } else if (shutdownBySignal || WEXITSTATUS(status) < 3) { /* 1 - shutdown, 2 - halt, 3 - triple fault. others - error */ if (vm->def->onPoweroff == VIR_DOMAIN_LIFECYCLE_ACTION_RESTART || vm->def->onPoweroff == VIR_DOMAIN_LIFECYCLE_ACTION_RESTART_RENAME) { -- 2.55.0

2 1

Re: Property types changed in this series
by Markus Armbruster 22 Oct '26

22 Oct '26

Libvirt developers: does libvirt use member @type of the reply of qom-list, qom-list-properties, qom-list-get? I'm asking because Marc-André's work changes many values to add a more useful replacement. I think we should deprecate @type. I'd like to find out whether we need to preserve the values for the deprecation grace period. Markus Armbruster <armbru(a)redhat.com> writes: > I used qom-list-types and qom-list-properties to list all properties and > their types, then looked for changes. This can miss changes in > dynamically created properties; see the note on qom-list-properties in > qapi/qom.json. Moreover, I ran into a few QOM types where > qom-list-properties is broken. These are ast2700-a1, ast2700-a2, and several riscv CPUs. A fix for the latter has been queued. > 1. Close misses of QAPI type names change to actual QAPI type names > > old property type new property type > --------------------------------------------- > string str > uint64_t uint64 > uint64_t size > int32_t int32 > int size > uint32_t uint32 > [uint16] uint16List > NotifyVMexitOption NotifyVmexitOption > CXLFixedMemoryWindow CXLFixedMemoryWindowOptionsList > > 2. Incorrect QAPI type names change to correct ones > > old property type new property type > --------------------------------------------- > SgxEPC SgxEPCList > QAuthZListRule QAuthZListRuleList > X86CPUFeatureWordInfo X86CPUFeatureWordInfoList > bool Pca9552LedState > > 3. Less than useful QAPI type names change to more useful ones > > old property type new property type > --------------------------------------------- > str Pca9552PinState > str Pca9554PinState > > 4. Lazy crap > > old property type new property type > --------------------------------------------- > list link<arm-cpu>List > list strList > list uint16List > list uint32List > list uint64List > list uint8List > struct any > > I'm not sure the first one is what it should be. > > I need to have a closer look at the last one. > > 5. Inventive crap > > old property type new property type > --------------------------------------------- > busnr uint8 > guest statistics VirtioBalloonGuestStats > loadparm str > on|off|split OnOffSplit > struct tm StructTm > > 6. An odd duck > > old property type new property type > --------------------------------------------- > str int32 > > This is pci-device property addr. See PATCH 54. > > On the way, I noted properties with anti-social names: > > QOM type name property name > --------------------------------- > acpi-ged memhp container[0] > e500-spin e500 spin pv device[0]

2 1