- Devel - libvirt List Archives

[PATCH 0/3] various cleanups
by Peter Krempa 20 Mar '26

20 Mar '26

Cleanups of stuff noticed during recent review of backup NBD port allocation. Peter Krempa (3): qemu: backup: Move setup of VIR_STORAGE_NET_HOST_TRANS_FD to qemuBackupPrepare qemu: conf: Don't use VIR_ERR_INTERNAL_ERROR for config file parsing errors qemuTranslateSnapshotDiskSourcePool: Use proper error code src/qemu/qemu_backup.c | 52 +++++++++++++++++++++--------------------- src/qemu/qemu_conf.c | 22 +++++++++--------- 2 files changed, 37 insertions(+), 37 deletions(-) -- 2.53.0

2 4

[PATCH (pushed) v2 0/3] qemu: add automatic port allocation for pull-mode backup NBD servers
by Peter Krempa 20 Mar '26

20 Mar '26

Split version of the original posting; posted as reference but already pushed with my R-b's. Lucas Amaral (3): qemu: conf: add setup for automatic port allocation for pull-mode backup NBD servers qemu: driver: Setup 'virPortAllocator' for backup NBD server ports qemu: add automatic port allocation for pull-mode backup NBD servers docs/formatbackup.rst | 3 ++- src/qemu/libvirtd_qemu.aug | 2 ++ src/qemu/qemu.conf.in | 9 +++++++++ src/qemu/qemu_backup.c | 30 ++++++++++++++++++++---------- src/qemu/qemu_conf.c | 25 +++++++++++++++++++++++++ src/qemu/qemu_conf.h | 6 ++++++ src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 6 ++++++ src/qemu/test_libvirtd_qemu.aug.in | 2 ++ 9 files changed, 73 insertions(+), 11 deletions(-) -- 2.53.0

1 3

[PATCH] qemu: add automatic port allocation for pull-mode backup NBD servers
by Lucas Amaral 20 Mar '26

20 Mar '26

Previously, users had to manually specify a TCP port when starting a pull-mode backup with an NBD server. A TODO comment in qemuBackupPrepare() noted this limitation and pointed toward using virPortAllocator, as done for migration, VNC, and SPICE ports. Add backup_port_min and backup_port_max configuration options to qemu.conf, defaulting to 10809-10872 (10809 is the IANA-assigned NBD port; range of 64 matches the migration port pattern). When a pull-mode backup is started without specifying a TCP port, a port is now acquired automatically from the configured range via virPortAllocatorAcquire(). The port is released when the backup ends or if startup fails. Signed-off-by: Lucas Amaral <lucaaamaral(a)gmail.com> --- Build-tested and passed full test suite on CentOS Stream 9 (298 OK, 0 failures). Runtime-validated against an actual patched virtqemud instance running inside a privileged container (CentOS Stream 9, QEMU 10.1.0) with a live aarch64/virt guest. Config parsing validation: - Default config (no backup_port_* set): daemon starts OK - Custom range (backup_port_min=20000, backup_port_max=20010): daemon starts OK - Invalid (min > max): daemon correctly refuses to start - Invalid (min = 0): daemon correctly refuses to start - Invalid (max > 65535): daemon correctly refuses to start Port auto-allocation (live VM backup): - Pull-mode backup WITHOUT port specified: backup-begin succeeds, backup-dumpxml shows auto-allocated port='10809' from default range. Previously this would fail with: "<domainbackup> must specify TCP port for now" - Pull-mode backup WITH explicit port=10809: backup-begin succeeds, backup-dumpxml shows port='10809'. Behavior unchanged from before the patch. Port conflict and exhaustion (range set to 10809-10810, 3 VMs): - Auto-allocate on vm1 (got 10809), then manual port=10809 on vm2: QEMU correctly rejects with "Address already in use" - Auto-allocate vm1=10809, vm2=10810 (range full), vm3 attempt: "Unable to find an unused port in range 'backup' (10809-10810)" - After aborting vm1 backup (releasing 10809), vm3 retries and gets 10809: port release and reuse works correctly docs/formatbackup.rst | 3 ++- src/qemu/libvirtd_qemu.aug | 2 ++ src/qemu/qemu.conf.in | 9 ++++++++ src/qemu/qemu_backup.c | 33 +++++++++++++++++++++--------- src/qemu/qemu_conf.c | 25 ++++++++++++++++++++++ src/qemu/qemu_conf.h | 6 ++++++ src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 6 ++++++ src/qemu/test_libvirtd_qemu.aug.in | 2 ++ 9 files changed, 76 insertions(+), 11 deletions(-) diff --git a/docs/formatbackup.rst b/docs/formatbackup.rst index df6392e3bd..24857eaf72 100644 --- a/docs/formatbackup.rst +++ b/docs/formatbackup.rst @@ -42,7 +42,8 @@ were supplied). The following child elements and attributes are supported: ```protocol`` element of a disk <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ attached via NBD in the domain (such as transport, socket, name, port, or tls), necessary to set up an NBD server that exposes the content of each disk at - the time the backup is started. + the time the backup is started. For TCP transport, if ``port`` is omitted, a + port is allocated automatically from the range configured in ``/etc/libvirt/qemu.conf``. In addition to the above the NBD server used for backups allows using ``transport='fd' fdgroup='NAME'`` where ``NAME`` is the name used with diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug index 0286582169..eb790d48be 100644 --- a/src/qemu/libvirtd_qemu.aug +++ b/src/qemu/libvirtd_qemu.aug @@ -146,6 +146,8 @@ module Libvirtd_qemu = | int_entry "migration_port_min" | int_entry "migration_port_max" | str_entry "migration_host" + | int_entry "backup_port_min" + | int_entry "backup_port_max" let log_entry = bool_entry "log_timestamp" diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in index 2d1c67034d..5eacd70022 100644 --- a/src/qemu/qemu.conf.in +++ b/src/qemu/qemu.conf.in @@ -969,6 +969,15 @@ #migration_port_max = 49215 +# Port range used for automatic allocation of NBD backup server ports. +# When a pull-mode backup is started without specifying a TCP port, a +# port from this range will be assigned automatically. The NBD standard +# port is 10809. +# +#backup_port_min = 10809 +#backup_port_max = 10872 + + # Timestamp QEMU's log messages (if QEMU supports it) # # Defaults to 1. diff --git a/src/qemu/qemu_backup.c b/src/qemu/qemu_backup.c index 44514d08fc..12ef64b14e 100644 --- a/src/qemu/qemu_backup.c +++ b/src/qemu/qemu_backup.c @@ -32,6 +32,7 @@ #include "storage_source.h" #include "storage_source_conf.h" #include "virerror.h" +#include "virportallocator.h" #include "virlog.h" #include "virbuffer.h" #include "backup_conf.h" @@ -71,16 +72,7 @@ qemuBackupPrepare(virDomainBackupDef *def) switch (def->server->transport) { case VIR_STORAGE_NET_HOST_TRANS_TCP: - /* TODO: Update qemu.conf to provide a port range, - * probably starting at 10809, for obtaining automatic - * port via virPortAllocatorAcquire, as well as store - * somewhere if we need to call virPortAllocatorRelease - * during BackupEnd. Until then, user must provide port */ - if (!def->server->port) { - virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("<domainbackup> must specify TCP port for now")); - return -1; - } + /* port is auto-allocated if not set */ break; case VIR_STORAGE_NET_HOST_TRANS_UNIX: @@ -841,6 +833,16 @@ qemuBackupBegin(virDomainObj *vm, if (qemuBackupPrepare(def) < 0) goto endjob; + if (pull && def->server && + def->server->transport == VIR_STORAGE_NET_HOST_TRANS_TCP && + !def->server->port) { + unsigned short port = 0; + if (virPortAllocatorAcquire(priv->driver->backupPorts, &port) < 0) + goto endjob; + def->server->port = port; + priv->backupNBDPort = port; + } + if (qemuBackupBeginPrepareTLS(vm, cfg, def, &tlsProps, &tlsSecretProps) < 0) goto endjob; @@ -969,6 +971,11 @@ qemuBackupBegin(virDomainObj *vm, qemuDomainObjExitMonitor(vm); } + if (ret < 0 && priv->backupNBDPort) { + virPortAllocatorRelease(priv->backupNBDPort); + priv->backupNBDPort = 0; + } + if (ret < 0 && !job_started && priv->backup) def = g_steal_pointer(&priv->backup); @@ -1026,6 +1033,12 @@ qemuBackupNotifyBlockjobEndStopNBD(virDomainObj *vm, qemuDomainObjExitMonitor(vm); backup->nbdStopped = true; + + if (priv->backupNBDPort) { + virPortAllocatorRelease(priv->backupNBDPort); + priv->backupNBDPort = 0; + backup->server->port = 0; + } } diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index de6e51177a..99e6a29148 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -74,6 +74,9 @@ VIR_LOG_INIT("qemu.qemu_conf"); #define QEMU_MIGRATION_PORT_MIN 49152 #define QEMU_MIGRATION_PORT_MAX 49215 +#define QEMU_BACKUP_PORT_MIN 10809 +#define QEMU_BACKUP_PORT_MAX 10872 + VIR_ENUM_IMPL(virQEMUSchedCore, QEMU_SCHED_CORE_LAST, "none", @@ -265,6 +268,9 @@ virQEMUDriverConfig *virQEMUDriverConfigNew(bool privileged, cfg->migrationPortMin = QEMU_MIGRATION_PORT_MIN; cfg->migrationPortMax = QEMU_MIGRATION_PORT_MAX; + cfg->backupPortMin = QEMU_BACKUP_PORT_MIN; + cfg->backupPortMax = QEMU_BACKUP_PORT_MAX; + /* For privileged driver, try and find hugetlbfs mounts automatically. * Non-privileged driver requires admin to create a dir for the * user, chown it, and then let user configure it manually. */ @@ -985,6 +991,25 @@ virQEMUDriverConfigLoadNetworkEntry(virQEMUDriverConfig *cfg, return -1; } + if (virConfGetValueUInt(conf, "backup_port_min", &cfg->backupPortMin) < 0) + return -1; + if (cfg->backupPortMin <= 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("%1$s: backup_port_min: port must be greater than 0"), + filename); + return -1; + } + + if (virConfGetValueUInt(conf, "backup_port_max", &cfg->backupPortMax) < 0) + return -1; + if (cfg->backupPortMax > 65535 || + cfg->backupPortMax < cfg->backupPortMin) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("%1$s: backup_port_max: port must be between the minimal port %2$d and 65535"), + filename, cfg->backupPortMin); + return -1; + } + if (virConfGetValueString(conf, "migration_host", &cfg->migrateHost) < 0) return -1; virStringStripIPv6Brackets(cfg->migrateHost); diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h index c284e108a1..2e68f1de14 100644 --- a/src/qemu/qemu_conf.h +++ b/src/qemu/qemu_conf.h @@ -240,6 +240,9 @@ struct _virQEMUDriverConfig { unsigned int migrationPortMin; unsigned int migrationPortMax; + unsigned int backupPortMin; + unsigned int backupPortMax; + bool logTimestamp; bool stdioLogD; @@ -338,6 +341,9 @@ struct _virQEMUDriver { /* Immutable pointer, immutable object */ virPortAllocatorRange *migrationPorts; + /* Immutable pointer, immutable object */ + virPortAllocatorRange *backupPorts; + /* Immutable pointer, lockless APIs */ virSysinfoDef *hostsysinfo; diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 5755d2adb0..1153d8c6e0 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -147,6 +147,7 @@ struct _qemuDomainObjPrivate { char *origname; int nbdPort; /* Port used for migration with NBD */ unsigned short migrationPort; + unsigned short backupNBDPort; int preMigrationState; unsigned long long preMigrationMemlock; /* Original RLIMIT_MEMLOCK in case it was changed for the current diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index c5eedeedfa..a8034b4f26 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -714,6 +714,12 @@ qemuStateInitialize(bool privileged, cfg->migrationPortMax)) == NULL) goto error; + if ((qemu_driver->backupPorts = + virPortAllocatorRangeNew(_("backup"), + cfg->backupPortMin, + cfg->backupPortMax)) == NULL) + goto error; + if (qemuSecurityInit(qemu_driver) < 0) goto error; diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in index 82cfec3b4b..2582c6a09c 100644 --- a/src/qemu/test_libvirtd_qemu.aug.in +++ b/src/qemu/test_libvirtd_qemu.aug.in @@ -110,6 +110,8 @@ module Test_libvirtd_qemu = { "migration_host" = "host.example.com" } { "migration_port_min" = "49152" } { "migration_port_max" = "49215" } +{ "backup_port_min" = "10809" } +{ "backup_port_max" = "10872" } { "log_timestamp" = "0" } { "nvram" { "1" = "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" } -- 2.52.0

2 1

[libvirt PATCH 00/11] Introduce support to pass iommu FD to libvirt
by Pavel Hrdina 20 Mar '26

20 Mar '26

Pavel Hrdina (11): conf: Move and rename virStorageSourceFDTuple object conf: Refactor virHostdevIsPCIDevice hypervisor: Fix virHostdevNeedsVFIO detection qemu: Expand call to qemuDomainNeedsVFIO qemu: Update qemuDomainNeedsVFIO to ignore PCI hostdev with IOMMUFD src: Use virHostdevIsPCIDeviceWith* to check for IOMMUFD conf: Introduce domain iommufd element qemu: Implement iommufd conf: Add iommufd fdgroup support qemu: Implement iommufd fdgroup tests: Add iommufd fdgroup test docs/formatdomain.rst | 27 +++++ src/conf/domain_conf.c | 114 +++++++++++++++++- src/conf/domain_conf.h | 9 ++ src/conf/domain_validate.c | 16 +++ src/conf/meson.build | 1 + src/conf/schemas/domaincommon.rng | 15 +++ src/conf/storage_source_conf.c | 42 ------- src/conf/storage_source_conf.h | 24 +--- src/conf/virdomainfd.c | 52 ++++++++ src/conf/virdomainfd.h | 27 +++++ src/hypervisor/virhostdev.c | 2 +- src/libvirt_private.syms | 7 +- src/qemu/qemu_backup.c | 2 +- src/qemu/qemu_cgroup.c | 2 +- src/qemu/qemu_command.c | 6 +- src/qemu/qemu_domain.c | 21 +++- src/qemu/qemu_domain.h | 3 +- src/qemu/qemu_driver.c | 6 +- src/qemu/qemu_hotplug.c | 6 +- src/qemu/qemu_namespace.c | 2 +- src/qemu/qemu_process.c | 55 ++++++++- src/qemu/qemu_processpriv.h | 2 + src/qemu/qemu_validate.c | 2 +- src/security/security_apparmor.c | 2 +- src/security/security_dac.c | 4 +- src/security/security_selinux.c | 4 +- src/security/virt-aa-helper.c | 2 +- tests/genericxml2xmlindata/iommufd.xml | 18 +++ tests/genericxml2xmltest.c | 2 + .../iommufd-q35-fd.x86_64-latest.args | 41 +++++++ .../iommufd-q35-fd.x86_64-latest.xml | 60 +++++++++ tests/qemuxmlconfdata/iommufd-q35-fd.xml | 38 ++++++ tests/qemuxmlconftest.c | 9 +- tests/testutilsqemu.c | 2 +- 34 files changed, 522 insertions(+), 103 deletions(-) create mode 100644 src/conf/virdomainfd.c create mode 100644 src/conf/virdomainfd.h create mode 100644 tests/genericxml2xmlindata/iommufd.xml create mode 100644 tests/qemuxmlconfdata/iommufd-q35-fd.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd-q35-fd.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd-q35-fd.xml -- 2.53.0

2 23

Re: [PATCH RFC 02/12] migration/qapi: Rename MigrationStats to MigrationRAMStats
by Peter Xu 20 Mar '26

20 Mar '26

On Thu, Mar 19, 2026 at 07:12:52PM -0400, Peter Xu wrote: > This stats is only about RAM, so make it accurate. This paves way for > statistics for all devices. > > Note that even if this is part of qapi/, this should not be part of ABI of > at least query-migrate, because the structure is not changed, and this > stats is always reported only under the "ram" section. > > Cc: Daniel P. Berrangé <berrange(a)redhat.com> > Cc: Markus Armbruster <armbru(a)redhat.com> > Cc: Libvirt Mailing List <libvir-list(a)redhat.com> I got the address wrong.. Will update when I repost. Copying the correct one. > Signed-off-by: Peter Xu <peterx(a)redhat.com> > --- > docs/about/removed-features.rst | 2 +- > qapi/migration.json | 8 ++++---- > migration/migration-stats.h | 2 +- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst > index 6f4447993c..7c4f4325f7 100644 > --- a/docs/about/removed-features.rst > +++ b/docs/about/removed-features.rst > @@ -699,7 +699,7 @@ was superseded by ``sections``. > ``query-migrate`` return value member ``skipped`` (removed in 9.1) > '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' > > -Member ``skipped`` of the ``MigrationStats`` struct hasn't been used > +Member ``skipped`` of the ``MigrationRAMStats`` struct hasn't been used > for more than 10 years. Removed with no replacement. > > ``migrate`` command option ``inc`` (removed in 9.1) > diff --git a/qapi/migration.json b/qapi/migration.json > index 7134d4ce47..cfc6ccee26 100644 > --- a/qapi/migration.json > +++ b/qapi/migration.json > @@ -12,7 +12,7 @@ > { 'include': 'sockets.json' } > > ## > -# @MigrationStats: > +# @MigrationRAMStats: > # > # Detailed migration status. > # > @@ -64,7 +64,7 @@ > # > # Since: 0.14 > ## > -{ 'struct': 'MigrationStats', > +{ 'struct': 'MigrationRAMStats', > 'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' , > 'duplicate': 'int', > 'normal': 'int', > @@ -209,7 +209,7 @@ > # If this field is not returned, no migration process has been > # initiated > # > -# @ram: `MigrationStats` containing detailed migration status, only > +# @ram: `MigrationRAMStats` containing detailed migration status, only > # returned if status is 'active' or 'completed'(since 1.2) > # > # @xbzrle-cache: `XBZRLECacheStats` containing detailed XBZRLE > @@ -309,7 +309,7 @@ > # Since: 0.14 > ## > { 'struct': 'MigrationInfo', > - 'data': {'*status': 'MigrationStatus', '*ram': 'MigrationStats', > + 'data': {'*status': 'MigrationStatus', '*ram': 'MigrationRAMStats', > '*vfio': 'VfioStats', > '*xbzrle-cache': 'XBZRLECacheStats', > '*total-time': 'int', > diff --git a/migration/migration-stats.h b/migration/migration-stats.h > index c0f50144c9..1153520f7a 100644 > --- a/migration/migration-stats.h > +++ b/migration/migration-stats.h > @@ -27,7 +27,7 @@ > > /* > * These are the ram migration statistic counters. It is loosely > - * based on MigrationStats. > + * based on MigrationRAMStats. > */ > typedef struct { > /* > -- > 2.50.1 > -- Peter Xu

1 0

[PATCH] qemuMigrationSrcBeginPhase: Don't call 'qemuBlockNodesEnsureActive' with offline VM
by Peter Krempa 18 Mar '26

18 Mar '26

From: Peter Krempa <pkrempa(a)redhat.com> Commits 7b5566ce67b18a and f879d5f40385358 ( v11.8.0-92-gf879d5f403 ) moved around code for re-activating block backends after migration. While previously it was done when migration failed now we do it when we need qemu to do some block operations. Commit 7b5566ce67b18a introduced a bug where 'qemuBlockNodesEnsureActive' is called also when the VM is offline (for migration with 'VIR_MIGRATE_OFFLINE'). That doesn't work though as attempting to enter the monitor of an inactive VM returns failure. Address it by calling 'qemuBlockNodesEnsureActive' only on active VMs during migration. Fixes: 7b5566ce67b18a2bebe68fdb07e046f25185f8d3 Resolves: https://redhat.atlassian.net/browse/RHEL-156800 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_migration.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index fec808ccfb..3141018a78 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2870,7 +2870,8 @@ qemuMigrationSrcBeginPhase(virQEMUDriver *driver, vm->newDef && !qemuDomainVcpuHotplugIsInOrder(vm->newDef))) cookieFlags |= QEMU_MIGRATION_COOKIE_CPU_HOTPLUG; - if (qemuBlockNodesEnsureActive(vm, vm->job->asyncJob) < 0) + if (virDomainObjIsActive(vm) && + qemuBlockNodesEnsureActive(vm, vm->job->asyncJob) < 0) return NULL; return qemuMigrationSrcBeginXML(vm, xmlin, -- 2.53.0

2 1

Plans for 12.2.0 release (freeze on 2026-03-26)
by Jiri Denemark 18 Mar '26

18 Mar '26

We are getting close to 12.2.0 release of libvirt. To aim for the release on Wednesday 01 Apr I suggest entering the freeze on Thursday 26 Mar and tagging RC2 on Monday 30 Mar. I hope this works for everyone. Jirka

1 0

[PATCH] virt-aa-helper : grant access to unix socket for qgsd
by Hector Cao 18 Mar '26

18 Mar '26

For quote generation and remote attestation, Intel TDX VM communicates with the QGSD (Quote Generation Service) on the host via unix socket. The unix socket can be specified via: <launchSecurity type='tdx'> ... <quoteGenerationService path='/var/run/tdx-qgs/qgs.socket'/> </launchSecurity> in case the path field is omitted, a default path is used. This commit generates the needed rule in the dynamic AA profile for the VM. Signed-off-by: Hector Cao <hector.cao(a)canonical.com> --- src/security/virt-aa-helper.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index e932e79dab..53059ad5fa 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -1397,6 +1397,19 @@ get_files(vahControl * ctl) break; case VIR_DOMAIN_LAUNCH_SECURITY_PV: case VIR_DOMAIN_LAUNCH_SECURITY_TDX: + /* To communicate with the QGSD daemon running on the host, if we use the unix socket, + * allow the VM to access to the unix socket. + */ + if (ctl->def->sec->data.tdx.haveQGS) { + const char *qgsd_sock_file = QGS_UNIX_SOCKET_FILE; + if (ctl->def->sec->data.tdx.qgs_unix_path) { + qgsd_sock_file = ctl->def->sec->data.tdx.qgs_unix_path; + } + if (vah_add_file(&buf, qgsd_sock_file, "rw") != 0) { + return -1; + } + } + break; case VIR_DOMAIN_LAUNCH_SECURITY_NONE: case VIR_DOMAIN_LAUNCH_SECURITY_LAST: break; -- 2.43.0

3 3

[PATCH v3 0/1] virt-aa-helper : grant access to unix socket for qgsd
by Hector Cao 18 Mar '26

18 Mar '26

Thanks Daniel for the review, I fixed the indent in the previous mail but realized afterwards that I need to add an other improvement to the patch, even though functionally, the previous patch works. The change is about moving the VIR_DOMAIN_LAUNCH_SECURITY_PV case after VIR_DOMAIN_LAUNCH_SECURITY_TDX block. Hector Cao (1): virt-aa-helper : grant access to unix socket for qgsd src/security/virt-aa-helper.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) -- 2.43.0

1 1

[PATCH 0/5] qemuhotplug: Introduce interface-network-hostdev
by Michal Privoznik 17 Mar '26

17 Mar '26

*** BLURB HERE *** Michal Prívozník (5): tests: Drop WITH_QEMU from qemu specific tests binaries/libraries qemuxmlconftest: Separate fake drivers into a separate file virnetworkportxml2xmldata: Use different PCI address in plug-hostdev-pci.xml qemuhotplugtest: Use fake drivers qemuhotplug: Introduce interface-network-hostdev tests/meson.build | 5 +- tests/qemudomaincheckpointxml2xmltest.c | 31 +- tests/qemudomainsnapshotxml2xmltest.c | 29 +- tests/qemufakedrivers.c | 368 +++++++++++++++ tests/qemufakedrivers.h | 19 + tests/qemuhotplugtest.c | 20 + .../qemuhotplug-interface-network-hostdev.xml | 4 + ...ug-base-live+interface-network-hostdev.xml | 63 +++ tests/qemumemlocktest.c | 25 +- ...-virtio-teaming-network.x86_64-latest.args | 2 +- tests/qemuxmlconftest.c | 443 +++--------------- tests/testutilsqemu.c | 43 +- tests/testutilsqemu.h | 23 +- .../plug-hostdev-pci.xml | 2 +- 14 files changed, 588 insertions(+), 489 deletions(-) create mode 100644 tests/qemufakedrivers.c create mode 100644 tests/qemufakedrivers.h create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-interface-network-hostdev.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+interface-network-hostdev.xml -- 2.52.0

2 7

[PATCH] network: Don't enable ip_forward for VIR_NETWORK_FORWARD_OPEN
by Michal Privoznik 17 Mar '26

17 Mar '26

From: Michal Privoznik <mprivozn(a)redhat.com> For a network that's <forward mode="open"/> there are no firewall rules added. We should not assume that users will configure NAT, and if they do it should be their responsibility to enable IP forwarding too. Resolves: https://gitlab.com/libvirt/libvirt/-/work_items/863 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/network/bridge_driver.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index d50d42c98c..ecfce5d9a4 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -2080,8 +2080,9 @@ networkStartNetworkVirtual(virNetworkDriverState *driver, } } - /* If forward.type != NONE, turn on global IP forwarding */ - if (def->forward.type != VIR_NETWORK_FORWARD_NONE) { + /* If forward.type != NONE and != OPEN, turn on global IP forwarding */ + if (def->forward.type != VIR_NETWORK_FORWARD_NONE && + def->forward.type != VIR_NETWORK_FORWARD_OPEN) { if (v6present && !virNetDevIPCheckIPv6Forwarding()) goto error; /* Precise error message already provided */ -- 2.52.0

2 1

A few questions about libvirt-java
by Takashi Kajinami 17 Mar '26

17 Mar '26

Hi, I've been working in a downstream project using libvirt-java to manage resources in libvirt from our application written in Java. The library has been working well so far, but I'm interested in contributing further improvements of the library, such as; - Replace finalize by more modern mechanisms such as (Auto)Closeable (finalize is deprecated in recent OpenJDK versions) - Complete migration to maven (to get rid of maven-ant-tasks which was already retired) However some of the planned contributions (especially the ones listed above) have relatively large impact and I'd like to ask a few questions so that so that we can drive the effort more smoothly. 1. Do you think that these are good/reasonable improvements ? 2. May I request a new release ? The last release (0.5.3) was released 4 years ago and several changes such as new features have been merged since then. Creating a release allows us to mave backword incompatible changes with less user impact. 3. Can we bump minimum JDK version ? Current minimum JSK version supported by the library is 1.8.0 but this is quite old ELS. I wonder if we can bump it to a newer version such as OpenJDK 17 or even 21. This is required to replace "finalize". Is there requirement about the platform the library should support ? Any feedback or guidance is very much appreciated ! Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 3

[PATCH 0/3] Random improvements
by Michal Privoznik 17 Mar '26

17 Mar '26

I've noticed an old branch. I've accumulated these while working on the networkxmlconftest. Michal Prívozník (3): src: Drop NULL check before calling virBufferEscapeString() network: Format <ip/> element using virXMLFormatElement() networkxmlconftest: s/fail/cleanup/ src/conf/domain_conf.c | 17 ++-- src/conf/network_conf.c | 87 ++++++++----------- src/conf/node_device_conf.c | 4 +- src/qemu/qemu_domain.c | 16 ++-- .../nat-network-dns-hosts-modified.xml | 3 +- .../nat-network-dns-more-hosts.xml | 3 +- .../nat-network-dns-srv-record.xml | 12 +-- .../nat-network-dns-srv-records.xml | 12 +-- .../nat-network-dns-txt-modify-ok.xml | 12 +-- .../nat-network-dns-txt-none.xml | 12 +-- .../nat-network-dns-txt-records.xml | 12 +-- .../nat-network-forward-ifaces.xml | 12 +-- .../nat-network-host-updated.xml | 12 +-- .../nat-network-hosts.xml | 12 +-- .../nat-network-no-forward-ifaces.xml | 12 +-- .../nat-network-no-hosts.xml | 3 +- .../nat-network-no-range.xml | 12 +-- .../nat-network-one-host.xml | 12 +-- tests/networkxml2xmlupdateout/nat-network.xml | 12 +-- .../dhcp6-nat-network.expect.xml | 6 +- .../nat-network-dns-forward-plain.expect.xml | 3 +- ...network-dns-forwarder-no-resolv.expect.xml | 3 +- .../nat-network-dns-forwarders.expect.xml | 3 +- .../nat-network-dns-hosts.expect.xml | 3 +- .../nat-network-dns-local-domain.expect.xml | 3 +- ...-network-dns-srv-record-minimal.expect.xml | 12 +-- .../nat-network-dns-srv-record.expect.xml | 12 +-- .../nat-network-dns-srv-records.expect.xml | 12 +-- .../nat-network-dns-txt-record.expect.xml | 12 +-- .../nat-network-explicit-flood.expect.xml | 12 +-- ...nat-network-forward-nat-address.expect.xml | 12 +-- .../nat-network-forward-nat-ipv6.expect.xml | 3 +- ...-network-forward-nat-no-address.expect.xml | 12 +-- .../nat-network-mtu.expect.xml | 12 +-- .../nat-network-name-with-quotes.expect.xml | 12 +-- .../networkxmlconfdata/nat-network.expect.xml | 12 +-- .../open-network.expect.xml | 3 +- .../ptr-domains-auto.expect.xml | 12 +-- .../routed-network-no-dns.expect.xml | 3 +- .../routed-network.expect.xml | 3 +- tests/networkxmlconftest.c | 18 ++-- 41 files changed, 167 insertions(+), 293 deletions(-) -- 2.52.0

2 4

[PATCH] virt-aa-helper: Prevent spurious denials for AoE disks
by PUSHKARAJ PATIL 13 Mar '26

13 Mar '26

virt-aa-helper calls virStorageSourceGetMetadata before adding a disk path to a domain's apparmor profile. This probes the device and may trigger an AppArmor denial when the disk is an AoE device under /dev/etherd/. The return value of virStorageSourceGetMetadata is not checked, so the denial has no functional impact but results in noisy dmesg logs. Allow read access to /dev/etherd/e*.* in the virt-aa-helper profile to avoid these spurious denials. Signed-off-by: PUSHKARAJ PATIL <pushkaraj.patil(a)in.ibm.com> --- src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in | 1 + 1 file changed, 1 insertion(+) diff --git a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in index e209a8bff7..80e9ef2b08 100644 --- a/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in +++ b/src/security/apparmor/usr.lib.libvirt.virt-aa-helper.in @@ -73,6 +73,7 @@ profile virt-aa-helper @libexecdir@/virt-aa-helper { /**.vhd r, /**.[iI][sS][oO] r, /**/disk{,.*} r, + /dev/etherd/e*.* r, include if exists <local/usr.lib.libvirt.virt-aa-helper> } -- 2.50.1 (Apple Git-155)

1 0

[PATCH 0/4] libvirt: AMD IOMMU fixes
by Xiaotian Feng 13 Mar '26

13 Mar '26

This series refines libvirt's logic for large vCPU configurations (>255) on x86/q35 machine types. Historically, the threshold was tied to Intel's EIM capability, but the real requirement is x2APIC support for APIC IDs beyond 255. AMD platforms can satisfy this via xtsup on amd-iommu. Summary of changes: 1. Fix virDomainIOMMUDefEquals to include pt and xtsup attributes for proper checks. 2. Correct error messages for passthrough (pt) and xtsup attributes to reflect their actual names instead of "dma translation". 3. Rename QEMU_MAX_VCPUS_WITHOUT_EIM to QEMU_MAX_VCPUS_WITHOUT_X2APIC and update validation logic to accept either: - intel-iommu with eim='on', or - amd-iommu with xtsup='on' for guests with more than 255 vCPUs. Error messages now mention x2APIC mode instead of extended interrupt mode. 4. Add QEMU_CAPS_AMD_IOMMU_XTSUP capability and enable xtsup by default for AMD IOMMU when a Q35 domain has >255 vCPUs, similar to Intel EIM auto-enable logic. Also ensure intremap is turned on when required. This makes the behavior vendor-neutral and improves usability for AMD EPYC guests with large vCPU counts. No ABI changes beyond stricter equality checks; this is a clarification and extension of existing logic. Xiaotian Feng (4): conf: fix virDomainIOMMUDefEquals for amd_iommu conf: fix error log for passthrough and xtsup attributes conf: support >255 vcpu w/ amd-iommu xtsup qemu: Enable AMD IOMMU XTSUP by default src/conf/domain_conf.c | 6 ++++-- src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_postparse.c | 42 +++++++++++++++++++++++------------- src/qemu/qemu_validate.c | 11 +++++----- src/qemu/qemu_validate.h | 2 +- 6 files changed, 41 insertions(+), 23 deletions(-) -- 2.34.1

2 6

[PATCH] storage: mpath: fix error reporting in virStorageBackendGetMaps
by Lucas Amaral 13 Mar '26

13 Mar '26

virStorageBackendGetMaps() returns 1 on failure instead of the conventional -1, and does not call virReportError() in any of its error paths. On top of that, both callers silently discard the return value: virStorageBackendGetMaps() ignores the result of virStorageBackendCreateVols(), and virStorageBackendMpathRefreshPool() ignores the result of virStorageBackendGetMaps(). Fix all three issues: normalize error returns to -1, add virReportError() calls for each failure path in virStorageBackendGetMaps(), and check return values in both callers so that errors are properly propagated. Signed-off-by: Lucas Amaral <lucaaamaral(a)gmail.com> --- This is similar in spirit to commits e9b931d3e4 ("virpci: Report an error if virPCIGetVirtualFunctionIndex() fails") and 6c2c9e21ac ("virstorageobj: Make virStoragePoolObjAddVol() report an error on failure"), applying the same pattern to the mpath storage backend. Found while auditing storage backends for functions that return error codes without calling virReportError(). src/storage/storage_backend_mpath.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/src/storage/storage_backend_mpath.c b/src/storage/storage_backend_mpath.c index 9fc3983c52..a30153a93b 100644 --- a/src/storage/storage_backend_mpath.c +++ b/src/storage/storage_backend_mpath.c @@ -197,19 +197,25 @@ virStorageBackendGetMaps(virStoragePoolObj *pool) struct dm_names *names = NULL; if (!(dmt = dm_task_create(DM_DEVICE_LIST))) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to create devmapper task")); + retval = -1; goto out; } dm_task_no_open_count(dmt); if (!dm_task_run(dmt)) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to run devmapper task")); + retval = -1; goto out; } if (!(names = dm_task_get_names(dmt))) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to get devmapper device names")); + retval = -1; goto out; } @@ -218,7 +224,10 @@ virStorageBackendGetMaps(virStoragePoolObj *pool) goto out; } - virStorageBackendCreateVols(pool, names); + if (virStorageBackendCreateVols(pool, names) < 0) { + retval = -1; + goto out; + } out: if (dmt != NULL) @@ -248,7 +257,8 @@ virStorageBackendMpathRefreshPool(virStoragePoolObj *pool) virWaitForDevices(); - virStorageBackendGetMaps(pool); + if (virStorageBackendGetMaps(pool) < 0) + return -1; return 0; } -- 2.52.0

2 1

[libvirt PATCH] viriommufd: Set IOMMU_OPTION_RLIMIT_MODE only when running privileged
by Pavel Hrdina 13 Mar '26

13 Mar '26

From: Pavel Hrdina <phrdina(a)redhat.com> If libvirt daemon is running unprivileged it will fail so we should not even try to set it. Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_process.c | 2 +- src/util/viriommufd.c | 6 +++--- src/util/viriommufd.h | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index ab7cf03c0e..ecd05b4bf6 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -7732,7 +7732,7 @@ qemuProcessOpenIommuFd(virDomainObj *vm) VIR_DEBUG("Opening IOMMU FD for domain %s", vm->def->name); - if ((iommufd = virIOMMUFDOpenDevice()) < 0) + if ((iommufd = virIOMMUFDOpenDevice(priv->driver->privileged)) < 0) return -1; if (qemuSecuritySetImageFDLabel(priv->driver->securityManager, vm->def, iommufd) < 0) diff --git a/src/util/viriommufd.c b/src/util/viriommufd.c index b62d59241d..82920923a2 100644 --- a/src/util/viriommufd.c +++ b/src/util/viriommufd.c @@ -80,14 +80,14 @@ virIOMMUFDSetRLimitMode(int fd, bool processAccounting) } int -virIOMMUFDOpenDevice(void) +virIOMMUFDOpenDevice(bool privileged) { int fd = -1; if ((fd = open(VIR_IOMMU_DEV_PATH, O_RDWR | O_CLOEXEC)) < 0) virReportSystemError(errno, "%s", _("cannot open IOMMUFD device")); - if (virIOMMUFDSetRLimitMode(fd, true) < 0) { + if (privileged && virIOMMUFDSetRLimitMode(fd, true) < 0) { VIR_FORCE_CLOSE(fd); return -1; } @@ -98,7 +98,7 @@ virIOMMUFDOpenDevice(void) #else int -virIOMMUFDOpenDevice(void) +virIOMMUFDOpenDevice(bool privileged G_GNUC_UNUSED) { virReportError(VIR_ERR_NO_SUPPORT, "%s", _("IOMMUFD is not supported on this platform")); diff --git a/src/util/viriommufd.h b/src/util/viriommufd.h index 223f44eb5c..7bad5c7472 100644 --- a/src/util/viriommufd.h +++ b/src/util/viriommufd.h @@ -22,6 +22,6 @@ #define VIR_IOMMU_DEV_PATH "/dev/iommu" -int virIOMMUFDOpenDevice(void); +int virIOMMUFDOpenDevice(bool privileged); bool virIOMMUFDSupported(void); -- 2.53.0

2 1

[PATCH 0/5] hyperv: Implement basic snapshot query APIs
by Jonathon Jongsma 13 Mar '26

13 Mar '26

This is the first patch series adding snapshot support for the hyperv driver. It only implements the basic functions for querying information about snapshots and doesn't handle creating or deleting snapshots yet. Jonathon Jongsma (5): hyperv: Implement domainSnapshotLookupByName() hyperv: implement virDomainListAllSnapshots()/virDomainSnapshotNum() hyperv: implement virDomainSnapshotGetXMLDesc() hyperv: Implement virDomainSnapshotCurrent()/virDomainHasCurrentSnapshot() hyperv: Implement virDomainSnapshotGetParent() src/hyperv/hyperv_driver.c | 276 +++++++++++++++++++++++++++++++++++++ src/hyperv/hyperv_wmi.c | 20 +++ src/hyperv/hyperv_wmi.h | 7 + 3 files changed, 303 insertions(+) -- 2.53.0

2 7

virsh feature request: cold restart and/or synchronous shutdown option
by roy-orbitson＠devo.net.au 13 Mar '26

13 Mar '26

When libvirt components get updated on a hypervisor, VMs continue running with obsolete files. Programs like "needrestart" alert one to this condition with messages like: VM guests are running outdated hypervisor (qemu) binaries on this host: 'bazquux' with pid 1234 Normal restarting of a VM (from within or with `virsh reboot ...`) does not resolve it because it's 'warm'; VMs must be completely shut down then started again to utilise the updates. Afaik, to do so reliably, in a way that minimises downtime, requires scripts like this: (d=bazquux; virsh shutdown --domain "$d" && until LC_ALL=C LANG=C virsh domstate --domain "$d" | grep -Fi 'shut off' &> /dev/null; do echo ...; sleep 1; done && virsh start --domain "$d") Adding a timeout complicates that further. Options for this logic to be performed by virsh would be beneficial, as a single operation: virsh reboot --domain bazquux --cold And by allowing poweroff to wait: (d=bazquux; virsh shutdown --domain "$d" --synchronous && virsh start --domain "$d") The latter would also assist with scripting changes to a VM that can only be performed whilst it is not running (shutdown -> alter -> start). Ideally, these would accept `--timeout n` so that if the shutdown portion was not completed quickly enough, they would fail and exit with a non-zero status, and the former would not start the VM again. I'm not sure of a good way to handle this where `on_poweroff` is set to something that doesn't result in the machine being shut off.

5 8

[PATCH v1 0/1] rpc: fix virNetClient->error leak on teardown
by Leander Kohler 12 Mar '26

12 Mar '26

Hi all, this is my first contribution to libvirt upstream. I am with Cyberus Technology, where I work on cloud-hypervisor and its integration with OpenStack and libvirt. The following fixes a leak in virNetClient teardown. virNetClientMarkClose() may save the current error in client->error (via virSaveLastError()). We usually free that in virNetClientCloseLocked(), but we can also end up disposing the client without going through that cleanup. One path where this happens is: virConnectDispose() -> remoteConnectClose() -> doRemoteClose() -> virNetClientClose(priv->client) -> g_clear_pointer(&priv->client, virObjectUnref) In that case, client->error can stay allocated until finalization, and ASan reports a leak. Fix is to also clear client->error in virNetClientDispose() as a final fallback. I included an ASan trace below. Thanks, Leander --- Line numbers in this trace come from our downstream libvirt fork and may differ from upstream, but the call path/function names are the same. [ 276.247727] virtchd[4030]: ==4030==ERROR: LeakSanitizer: detected memory leaks Direct leak of 80 byte(s) in 1 object(s) allocated from: #0 0x7fcd6009e110 in calloc (libasan.so.8+0xfc110) #1 0x7fcd5dcb95bd in g_malloc0 (libglib-2.0.so.0+0x6d5bd) #2 0x7fcd5eb15f31 in virSaveLastError ../src/util/virerror.c:413 #3 0x7fcd5ee6c76c in virNetClientMarkClose ../src/rpc/virnetclient.c:776 #4 0x7fcd5ee6f782 in virNetClientCloseInternal ../src/rpc/virnetclient.c:837 #5 0x7fcd5f0150e4 in doRemoteClose ../src/remote/remote_driver.c:1414 #6 0x7fcd5f0150e4 in remoteConnectClose ../src/remote/remote_driver.c:1442 #7 0x7fcd5f1a90ef in virConnectDispose ../src/datatypes.c:174 #8 0x7fcd5ea58ebb in vir_object_finalize ../src/util/virobject.c:323 #9 0x7fcd5dc05c52 in g_object_unref (libgobject-2.0.so.0+0x1ec52) #10 0x7fcd5ea59fc7 in virObjectUnref ../src/util/virobject.c:377 #11 0x7fcd5ea59fc7 in virObjectUnref ../src/util/virobject.c:370 #12 0x7fcd5ef3a92f in glib_autoptr_clear_virConnect ../src/datatypes.h:548 #13 0x7fcd5ef3a92f in glib_autoptr_cleanup_virConnect ../src/datatypes.h:548 #14 0x7fcd5ef3a92f in virDomainInterfaceDeleteDevice ../src/hypervisor/domain_interface.c:419 #15 0x7fcd594a0cd3 in virCHProcessStopOrKill ../src/ch/ch_process.c:1308 #16 0x7fcd594a8bfa in virCHProcessStop ../src/ch/ch_process.c:1363 #17 0x7fcd5945d8c7 in chDomainDestroyFlags ../src/ch/ch_driver.c:959 #18 0x7fcd5f0f69c0 in virDomainDestroy ../src/libvirt-domain.c:514 #19 0x55c25777376a in remoteDispatchDomainDestroy src/remote/remote_daemon_dispatch_stubs.h:5485 #20 0x55c25777376a in remoteDispatchDomainDestroyHelper src/remote/remote_daemon_dispatch_stubs.h:5464 #21 0x7fcd5ee7c42c in virNetServerProgramDispatchCall ../src/rpc/virnetserverprogram.c:423 #22 0x7fcd5ee7c42c in virNetServerProgramDispatch ../src/rpc/virnetserverprogram.c:299 #23 0x7fcd5ee97c6c in virNetServerProcessMsg ../src/rpc/virnetserver.c:135 #24 0x7fcd5ee98b43 in virNetServerHandleJob ../src/rpc/virnetserver.c:155 #25 0x7fcd5eadbce2 in virThreadPoolWorker ../src/util/virthreadpool.c:164 #26 0x7fcd5eada3c9 in virThreadHelper ../src/util/virthread.c:256 #27 0x7fcd60004cd5 in asan_thread_start(void*) (libasan.so.8+0x62cd5) #28 0x7fcd5d200979 in start_thread (libc.so.6+0x9a979) #29 0x7fcd5d288d2b in __GI___clone3 (libc.so.6+0x122d2b) Objects leaked above: 0x507000064400 (80 bytes) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 1 allocation(s). Leander Kohler (1): rpc: free saved close error in virNetClientDispose src/rpc/virnetclient.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.51.2

2 2

[PATCH] util: implement virHostCPUGetOnlineBitmap() for FreeBSD
by Roman Bogorodskiy 12 Mar '26

12 Mar '26

Implement virHostCPUGetOnlineBitmap() for FreeBSD. As FreeBSD supports neither plugging nor taking CPUs offline, all CPUs are always online. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/util/virhostcpu.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index 7cecb4b2c8..8688b6ec67 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -1120,6 +1120,19 @@ virHostCPUGetOnlineBitmap(void) virFileReadValueBitmap(&ret, "%s/cpu/online", SYSFS_SYSTEM_PATH); + return ret; +#elif defined(__FreeBSD__) + virBitmap *ret = NULL; + int ncpus = virHostCPUGetCountAppleFreeBSD(); + + if (ncpus == -1) + return ret; + + /* FreeBSD does not support CPU hotplug, so it is safe to assume + * that all available CPUs are online */ + ret = virBitmapNew(ncpus); + virBitmapSetAll(ret); + return ret; #else virReportError(VIR_ERR_NO_SUPPORT, "%s", -- 2.52.0

2 1

[RFC PATCH v2 0/2] qemu: Support vCMDQ
by Nathan Chen 11 Mar '26

11 Mar '26

Hi, This is a follow up to the previous RFC patchset [0] for supporting Tegra241 vCMDQ. This patchset is tested with Shameer's v3 qemu series [1] for vCMDQ support. The accelerated SMMUv3 series for qemu and Libvirt [2] are pre-requisites for vCMDQ support, as accelerated SMMUv3 must be enabled alongside vCMDQ. A new 'cmdqv' <iommu> driver attribute is introduced to toggle enabling vCMDQ support. For instance, specifying hostdevs associated with multiple accelerated SMMUs + CMDQV enabled, configured to be routed to pcie-expander-bus controllers in a way where VFIO device to SMMUv3 associations are matched with the host: <devices> ... <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='252'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='248'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </controller> ... <controller type='pci' index='21' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='21' port='0x0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> <controller type='pci' index='22' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='22' port='0xa8'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> ... <hostdev mode='subsystem' type='pci' managed='no'> <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'> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> <iommu model='smmuv3'> <driver pciBus='1' accel='on' ats='on' ril='on' ssidSize='20' oas='44' cmdqv='on'/> </iommu> <iommu model='smmuv3'> <driver pciBus='2' accel='on' ats='on' ril='on' ssidSize='20' oas='44' cmdqv='on'/> </iommu> </devices> This would get translated to a qemu command line with the arguments below: -device '{"driver":"pxb-pcie","bus_nr":252,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \ -device '{"driver":"pxb-pcie","bus_nr":248,"id":"pci.2","bus":"pcie.0","addr":"0x2"}' \ -device '{"driver":"pcie-root-port","port":0,"chassis":21,"id":"pci.21","bus":"pci.1","addr":"0x0"}' \ -device '{"driver":"pcie-root-port","port":168,"chassis":22,"id":"pci.22","bus":"pci.2","addr":"0x0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.1","id":"iommu0","accel":true,"ats":true,"cmdqv":"on","ril":true,"pasid":true,"oas":44}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.2","id":"iommu1","accel":true,"ats":true,"cmdqv":"on","ril":true,"pasid":true,"oas":44}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","bus":"pci.22","addr":"0x0"}' \ This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/cmdqv-03-26/ Thanks, Nathan Changes from v1: - Remove 'identifier' attribute for SMMUv3 - Change QEMU command line property from 'tegra241-cmdqv' to 'cmdqv' - Support QEMU OnOffAuto CMDQV property instead of expecting a bool [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/NHVK… [1] https://lore.kernel.org/all/20260226105056.897-1-skolothumtho@nvidia.com/ [2] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5GG7… Nathan Chen (2): qemu: Support NVIDIA Tegra241 CMDQV for SMMUv3 tests: qemuxmlconfdata: provide cmdqv sample XML and CLI args docs/formatdomain.rst | 6 ++ src/conf/domain_conf.c | 15 ++++ src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 5 +- src/conf/schemas/domaincommon.rng | 5 ++ src/qemu/qemu_command.c | 1 + ...u-smmuv3-pci-bus-cmdqv.aarch64-latest.args | 45 +++++++++++ ...mu-smmuv3-pci-bus-cmdqv.aarch64-latest.xml | 76 +++++++++++++++++++ .../iommu-smmuv3-pci-bus-cmdqv.xml | 66 ++++++++++++++++ tests/qemuxmlconftest.c | 1 + 10 files changed, 220 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-cmdqv.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-cmdqv.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-cmdqv.xml -- 2.43.0

1 2

[PATCH v7 0/2] qemu: Support accelerated vSMMUs
by Nathan Chen 11 Mar '26

11 Mar '26

Hi, This is a follow up to the sixth RFC patchset [0] for supporting multiple accelerated vSMMU instances. Support for user-creatable accelerated SMMUv3 in QEMU has been applied to target-arm.next [1]. For instance, specifying hostdevs associated with multiple accelerated SMMUs, configured to be routed to pcie-expander-bus controllers in a way where VFIO device to SMMUv3 associations are matched with the host: <devices> ... <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='252'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='248'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </controller> ... <controller type='pci' index='21' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='21' port='0x0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> <controller type='pci' index='22' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='22' port='0xa8'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> ... <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <vpasidCapOffset>0xff8</vpasidCapOffset> <address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <vpasidCapOffset>0xff8</vpasidCapOffset> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> <iommu model='smmuv3'> <driver parentIdx='1' accel='on' ats='on' ril='off' ssidSize='20' oas='44'/> </iommu> <iommu model='smmuv3'> <driver parentIdx='2' accel='on' ats='on' ril='off' ssidSize='20' oas='44'/> </iommu> </devices> This would get translated to a qemu command line with the arguments below: -device '{"driver":"pxb-pcie","bus_nr":252,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \ -device '{"driver":"pxb-pcie","bus_nr":248,"id":"pci.2","bus":"pcie.0","addr":"0x2"}' \ -device '{"driver":"pcie-root-port","port":0,"chassis":21,"id":"pci.21","bus":"pci.1","addr":"0x0"}' \ -device '{"driver":"pcie-root-port","port":168,"chassis":22,"id":"pci.22","bus":"pci.2","addr":"0x0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.1","id":"iommu0","accel":true,"ats":true,"ril":false,"ssidsize":20,"oas":44}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.2","id":"iommu1","accel":true,"ats":true,"ril":false,"ssidsize":20,"oas":44}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","x-vpasid-cap-offset":4088,"bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","x-vpasid-cap-offset":4088,"bus":"pci.22","addr":"0x0"}' \ This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/smmuv3-accel-01-26-v7/ Thanks, Nathan Changes from v6: - Remove smmuv3 'pasid' attribute - Add smmuv3 'ssidsize' attribute - Add support for 'vpasidCapOffset' element - Modify logic for building accel smmuv3 qemu command line to omit ATS, RIL, accel flags when not needed (enabled/disabled by default in QEMU SMMUv3) [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/VRSS… [1] https://lore.kernel.org/qemu-devel/20260126104342.253965-1-skolothumtho@nvi… Nathan Chen (2): qemu: Add support for HW-accelerated nested SMMUv3 tests: qemuxmlconfdata: provide HW-accel smmuv3 sample XML and CLI args docs/formatdomain.rst | 36 +++++++ src/conf/domain_conf.c | 101 +++++++++++++++++- src/conf/domain_conf.h | 6 ++ src/conf/domain_validate.c | 36 ++++++- src/conf/schemas/domaincommon.rng | 32 ++++++ src/qemu/qemu_command.c | 23 ++++ src/util/virpci.h | 4 + ...u-smmuv3-pci-bus-accel.aarch64-latest.args | 38 +++++++ ...mu-smmuv3-pci-bus-accel.aarch64-latest.xml | 64 +++++++++++ .../iommu-smmuv3-pci-bus-accel.xml | 54 ++++++++++ tests/qemuxmlconftest.c | 1 + 11 files changed, 390 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel.xml -- 2.43.0

2 9

[PATCH 0/4] Add support for expanding CPU features in domain capabilities
by Jiri Denemark 11 Mar '26

11 Mar '26

Consistently with all other CPU definitions, domain capabilities report host-model CPU as a base model and additional list of features. Getting all features supported on a host is possible by passing the host-model CPU definition to hypervisor-cpu-baseline with --features option. But while this is very easy in virsh (domain capabilities can by directly piped to hypervisor-cpu-baseline), doing this via API is more complicated. The relevant part of the domain XML needs to be copied into a new XML document, formatted and passed to virConnectBaselineHypervisorCPU. This series adds the ability to expand CPU features directly in the domain capabilities XML without having to call another API. Jiri Denemark (4): Introduce EXPAND_CPU_FEATURES flag for domain capabilities qemu: Implement VIR_CONNECT_GET_DOMAIN_CAPABILITIES_EXPAND_CPU_FEATURES virsh: Add --expand-cpu-features option for domcapabilities docs: Clarify host-model description in domain capabilities docs/formatdomaincaps.rst | 4 ++++ docs/manpages/virsh.rst | 5 +++++ include/libvirt/libvirt-domain.h | 2 ++ src/libvirt-domain.c | 5 +++++ src/qemu/qemu_driver.c | 9 ++++++++- tools/virsh-host.c | 7 +++++++ 6 files changed, 31 insertions(+), 1 deletion(-) -- 2.53.0

2 5

[PATCH] tests: Create fake root dirs later
by Michal Privoznik 11 Mar '26

11 Mar '26

From: Michal Privoznik <mprivozn(a)redhat.com> In one of previous commits the virTestMain() function was changed to actually create fake HOME, XDG_RUNTIME_DIR, ... directories instead of setting spoofed values in the environment. But alongside with this, the call to virTestFakeRootDirInit() was moved (to location where environment was poisoned). And this would not matter if it wasn't for mocking. Because what we ended up with is virTestFakeRootDirInit() is called and then (optionally) the process re-execs itself (with mocks loaded). This means that previously created root dirs are never cleaned up and just pollute builddir. Therefore, restore original location from which the function was called. Fixes: 79d97d2b4f0b55ea80f8330144953e2b93927e25 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tests/testutils.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/testutils.c b/tests/testutils.c index c984f66d0e..14e5c56fcf 100644 --- a/tests/testutils.c +++ b/tests/testutils.c @@ -859,9 +859,6 @@ int virTestMain(int argc, preloads[npreloads] = NULL; } - if (!(fakerootdir = virTestFakeRootDirInit())) - return EXIT_FAILURE; - va_start(ap, func); while ((lib = va_arg(ap, const char *))) { g_autofree char *abs_lib_path = g_strdup_printf("%s/%s", abs_builddir, lib); @@ -934,6 +931,9 @@ int virTestMain(int argc, failedTests = virBitmapNew(1); + if (!(fakerootdir = virTestFakeRootDirInit())) + return EXIT_FAILURE; + ret = (func)(); virResetLastError(); -- 2.52.0

2 1