- Devel - libvirt List Archives

[PATCH RFC 0/5] qemu: Adjust to deprecation of -netdev tap properties 'fd' and 'vhostfd' - Variant B
by Peter Krempa 06 Feb '26

06 Feb '26

This patchset adapts libvirt to the proposed deprecation of 'fd'/'vhostfd' fields in favor of the plural spellings even for 1 fd. Based on the discussion [1] it seems that it should be possible to replace it unconditionally but I'm not certain about this and also it's outside my usual area of expertise. Thus this version is the more cautious approach of adding a capability and only switching the generator once deprecations are set up. While adding the capability I've also uncovered a bug in the QMP query strings where it was not possible to query features of an object member. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/SM4… Peter Krempa (5): virQEMUQAPISchemaTraverseObject: Consider features also on current members qemu: capabilities: Introduce QEMU_CAPS_NETDEV_TAP_FD_VHOSTFD_PLURAL qemuxmlconftest: Add version-locked test cases for the use of -netdev tap with fd/vhostfd qemuBuildHostNetProps: Use 'fds', 'vhostfds' with QEMU_CAPS_NETDEV_TAP_FD_VHOSTFD_PLURAL [DO_NOT_PUSH] qemucapabilitiesdata: Update with patches removing 'fd' and 'vhostfd' src/qemu/qemu_capabilities.c | 8 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 11 +- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_qapi.c | 26 + .../caps_11.0.0_x86_64.replies | 3571 ++++++++--------- .../caps_11.0.0_x86_64.xml | 11 +- .../downscript.x86_64-latest.args | 2 +- .../graphics-spice-timeout.x86_64-latest.args | 2 +- .../net-bandwidth.x86_64-latest.args | 2 +- .../net-bandwidth2.x86_64-latest.args | 2 +- .../net-coalesce.x86_64-latest.args | 6 +- .../net-eth-hostip.x86_64-latest.args | 2 +- .../net-eth-ifname.x86_64-latest.args | 2 +- .../net-eth-names.x86_64-latest.args | 4 +- .../net-eth-unmanaged-tap.x86_64-latest.args | 2 +- .../net-eth.x86_64-10.2.0.args | 36 + .../qemuxmlconfdata/net-eth.x86_64-10.2.0.xml | 44 + .../net-eth.x86_64-latest.args | 2 +- .../net-isolated-port.x86_64-latest.args | 2 +- .../net-midonet.x86_64-latest.args | 2 +- .../net-mtu.x86_64-latest.args | 4 +- .../net-openvswitch.x86_64-latest.args | 2 +- ...irtio-network-portgroup.x86_64-latest.args | 6 +- ...-virtio-teaming-network.x86_64-latest.args | 2 +- .../net-virtio-vhost.x86_64-10.2.0.args | 42 + .../net-virtio-vhost.x86_64-10.2.0.xml | 65 + .../net-virtio-vhost.x86_64-latest.args | 2 +- .../tap-vhost-incorrect.x86_64-latest.args | 4 +- .../user-aliases.x86_64-latest.args | 2 +- tests/qemuxmlconftest.c | 4 + 32 files changed, 2048 insertions(+), 1828 deletions(-) create mode 100644 tests/qemuxmlconfdata/net-eth.x86_64-10.2.0.args create mode 100644 tests/qemuxmlconfdata/net-eth.x86_64-10.2.0.xml create mode 100644 tests/qemuxmlconfdata/net-virtio-vhost.x86_64-10.2.0.args create mode 100644 tests/qemuxmlconfdata/net-virtio-vhost.x86_64-10.2.0.xml -- 2.53.0

1 5

[PATCH RFC 0/5] qemu: Adjust to deprecation of -netdev tap properties 'fd' and 'vhostfd' - Variant A
by Peter Krempa 06 Feb '26

06 Feb '26

This patchset adapts libvirt to the proposed deprecation of 'fd'/'vhostfd' fields in favor of the plural spellings even for 1 fd. Based on the discussion [1] it seems that it should be possible to replace it unconditionally but I'm not certain about this and also it's outside my usual area of expertise. This is the optimistic approach should it be possible for us to unconditionally use the plural variands. Reordering the patches shows that the proposal causes test suite failures in our code. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/SM4… Peter Krempa (2): qemuBuildHostNetProps: Use only plural form of 'fds' and 'vhostfds' properties [DO_NOT_PUSH] qemucapabilitiesdata: Update with patches removing 'fd' and 'vhostfd' src/qemu/qemu_command.c | 24 +- .../caps_11.0.0_x86_64.replies | 3571 ++++++++--------- .../caps_11.0.0_x86_64.xml | 10 +- .../downscript.x86_64-latest.args | 2 +- .../graphics-spice-timeout.x86_64-latest.args | 2 +- .../net-bandwidth.x86_64-latest.args | 2 +- .../net-bandwidth2.x86_64-latest.args | 2 +- .../net-coalesce.x86_64-latest.args | 6 +- .../net-eth-hostip.x86_64-latest.args | 2 +- .../net-eth-ifname.x86_64-latest.args | 2 +- .../net-eth-names.x86_64-latest.args | 4 +- .../net-eth-unmanaged-tap.x86_64-latest.args | 2 +- .../net-eth.x86_64-latest.args | 2 +- .../net-isolated-port.x86_64-latest.args | 2 +- .../net-midonet.x86_64-latest.args | 2 +- .../net-mtu.x86_64-latest.args | 4 +- .../net-openvswitch.x86_64-latest.args | 2 +- ...irtio-network-portgroup.x86_64-latest.args | 6 +- ...-virtio-teaming-network.x86_64-latest.args | 2 +- .../net-virtio-vhost.x86_64-latest.args | 2 +- .../tap-vhost-incorrect.x86_64-latest.args | 4 +- .../user-aliases.x86_64-latest.args | 2 +- 22 files changed, 1815 insertions(+), 1842 deletions(-) -- 2.53.0

1 2

[PATCH v2 0/2] target/arm: Deprecate '-cpu any'
by Philippe Mathieu-Daudé 06 Feb '26

06 Feb '26

Arm '-cpu any' is aliased to '-cpu max' since more than 5 years. Deprecate the former in preparation of removal. v2: s/any/max/ in target/arm/cpu.c comment Philippe Mathieu-Daudé (2): target/arm: Remove dead code target/arm: Deprecate '-cpu any' (remplaced by '-cpu max') docs/about/deprecated.rst | 8 ++++++++ target/arm/cpu.h | 2 +- target/arm/cpu.c | 1 + target/arm/tcg/cpu32.c | 3 --- 4 files changed, 10 insertions(+), 4 deletions(-) -- 2.52.0

3 7

[PATCH] hyperv: Avoid memleak in hypervDomainDefParsePhysicalDisk
by Michal Privoznik 06 Feb '26

06 Feb '26

From: Michal Privoznik <mprivozn(a)redhat.com> When parsing a physical disk, the @hostResouce is escaped once with the retval being stored into @hostEscaped. Then, it's escaped again, but the retval is stored into the very same variable, leading to a leak where intermediate value is lost. 256 bytes in 1 blocks are definitely lost in loss record 469 of 483 at 0x49543A0: realloc (vg_replace_malloc.c:1804) by 0x516C251: g_realloc (in /usr/lib64/libglib-2.0.so.0.8400.4) by 0x518BB7E: g_string_expand (in /usr/lib64/libglib-2.0.so.0.8400.4) by 0x518BFF9: g_string_insert_len (in /usr/lib64/libglib-2.0.so.0.8400.4) by 0x4A58B5F: g_string_append_len_inline (gstring.h:247) by 0x4A58B5F: virBufferAdd (virbuffer.c:164) by 0x4AFDA71: virStringReplace (virstring.c:708) by 0x4DA4381: hypervDomainDefParsePhysicalDisk (hyperv_driver.c:1375) by 0x4DA4A18: hypervDomainDefParseStorage (hyperv_driver.c:1487) by 0x4DA9E31: hypervDomainGetXMLDesc (hyperv_driver.c:2761) by 0x4DFB3E5: virDomainGetXMLDesc (libvirt-domain.c:2898) by 0x406D39B: cmdDumpXML (virsh-domain.c:10787) by 0x40B13B1: vshCommandRun (vsh.c:1383) Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/hyperv/hyperv_driver.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/hyperv/hyperv_driver.c b/src/hyperv/hyperv_driver.c index 8dd56f39dc..203bbeb8a5 100644 --- a/src/hyperv/hyperv_driver.c +++ b/src/hyperv/hyperv_driver.c @@ -1351,6 +1351,7 @@ hypervDomainDefParsePhysicalDisk(hypervPrivate *priv, virDomainDiskDef *disk = NULL; char **hostResource = entry->data->HostResource.data; g_autofree char *hostEscaped = NULL; + g_autofree char *hostEscapedTwice = NULL; g_autofree char *driveNumberStr = NULL; g_auto(virBuffer) query = VIR_BUFFER_INITIALIZER; int addr = -1, ctrlr_idx = -1; @@ -1373,12 +1374,12 @@ hypervDomainDefParsePhysicalDisk(hypervPrivate *priv, /* Query Msvm_DiskDrive for the DriveNumber */ hostEscaped = virStringReplace(*hostResource, "\\\"", "\""); - hostEscaped = virStringReplace(hostEscaped, "\\", "\\\\"); + hostEscapedTwice = virStringReplace(hostEscaped, "\\", "\\\\"); /* quotes must be preserved, so virBufferEscapeSQL can't be used */ virBufferAsprintf(&query, MSVM_DISKDRIVE_WQL_SELECT "WHERE __PATH='%s'", - hostEscaped); + hostEscapedTwice); if (hypervGetWmiClass(Msvm_DiskDrive, &diskdrive) < 0) goto cleanup; -- 2.52.0

2 1

[PATCH] virt-aa-helper: Fix unchecked return values
by Dmitry Lopatin 06 Feb '26

06 Feb '26

Add missing return value checks to fix the following issues reported by the static analyzer: - vah_add_file() call when adding render node path to the AppArmor profile (line 1029) was not checked, while there are examples with return code check throughout the code. - vah_add_file() call when adding default render node path (line 1037) had the same issue. - virDriverLoadModule() call when loading the storage driver (line 908) was not checked, while there are examples with return code check throughout the code. Signed-off-by: Dmitry Lopatin <dmitry.lopatin(a)flant.com> --- src/security/virt-aa-helper.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index 067a17f331..07e5882237 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -905,7 +905,8 @@ get_files(vahControl * ctl) /* load the storage driver so that backing store can be accessed */ #ifdef WITH_STORAGE - virDriverLoadModule("storage", "storageRegister", false); + if (virDriverLoadModule("storage", "storageRegister", false) < 0) + goto cleanup; #endif for (i = 0; i < ctl->def->ndisks; i++) { @@ -1026,7 +1027,8 @@ get_files(vahControl * ctl) const char *rendernode = virDomainGraphicsGetRenderNode(graphics); if (rendernode) { - vah_add_file(&buf, rendernode, "rw"); + if (vah_add_file(&buf, rendernode, "rw") != 0) + goto cleanup; needsgl = true; } else { if (virDomainGraphicsNeedsAutoRenderNode(graphics)) { @@ -1034,7 +1036,8 @@ get_files(vahControl * ctl) needsgl = true; if (defaultRenderNode) { - vah_add_file(&buf, defaultRenderNode, "rw"); + if (vah_add_file(&buf, defaultRenderNode, "rw") != 0) + goto cleanup; VIR_FREE(defaultRenderNode); } } -- 2.34.1

5 9

[PATCH] src/esx/esx_vi.c: Debug path element comparisons
by Richard W.M. Jones 06 Feb '26

06 Feb '26

Libvirt vpx:// and esx:// URIs are quite obscure. In particular it is very difficult to construct a correct path to a VMware resource. Basically you are iterating over VMware structures blindly with no way to know what your choices are at each level in the path. This commit doesn't directly address this. It's still difficult. But at least let's add the true path choices to the debug output so someone could in theory use 'LIBVIRT_DEBUG=1' to find out what possible choices exist at a path level. For example this command fails because the label (which looks like an IPv6 address, but is really a label) should use "::" instead of ":0:": LIBVIRT_DEBUG=1 virsh -c 'vpx://root@.../data/aaaa:52:0:49e0:2eea:7fff:fee6:eca0/?no_verify=1' In the debugging output we now print: 2026-02-05 10:58:25.421+0000: 1528876: debug : esxVI_LookupManagedObjectHelper:4956 : comparing path element 'aaaa:52:0:49e0:2eea:7fff:fee6:eca0' with candidate name 'aaaa:52::49e0:2eea:7fff:fee6:eca0' 2026-02-05 10:58:25.421+0000: 1528876: error : esxVI_Context_LookupManagedObjectsByPath:1098 : internal error: Could not find compute resource specified in '/data/aaaa:52:0:49e0:2eea:7fff:fee6:eca0/' In an ideal world we should improve the error message to show the possible choices, but the way the code is structured makes that prohibitive. Related: https://issues.redhat.com/browse/RHEL-145080 --- src/esx/esx_vi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c index 8d2ffb3f8f..cfd783622d 100644 --- a/src/esx/esx_vi.c +++ b/src/esx/esx_vi.c @@ -4953,6 +4953,8 @@ esxVI_LookupManagedObjectHelper(esxVI_Context *ctx, goto cleanup; } + VIR_DEBUG("comparing path element '%s' with candidate name '%s'", + name, name_candidate); if (STREQ(name_candidate, name)) { /* Found item with matching name */ break; -- 2.52.0

2 2

[PATCH v5 02/23] vhost: drop backend_features field
by Vladimir Sementsov-Ogievskiy 06 Feb '26

06 Feb '26

This field is mostly unused and sometimes confusing. We even have a TODO-like comment to drop it, the comment is removed in this commit. The field is used to held VHOST_USER_F_PROTOCOL_FEATURES for vhost-user and/or VHOST_NET_F_VIRTIO_NET_HDR for vhost-net (which may be vhost-user-net). But we can simply recalculate these two flags in place from hdev->features, and from net-client for VHOST_NET_F_VIRTIO_NET_HDR. Note: removing field from x-query-virtio-status result is incompatible change. We can do it because the command is unstable. Cc: devel(a)lists.libvirt.org Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov(a)yandex-team.ru> Acked-by: Markus Armbruster <armbru(a)redhat.com> Reviewed-by: Daniil Tatianin <d-tatianin(a)yandex-team.ru> Acked-by: Raphael Norwitz <raphael.s.norwitz(a)gmail.com> --- hw/block/vhost-user-blk.c | 1 - hw/net/vhost_net.c | 26 ++++++++++++++------------ hw/scsi/vhost-scsi.c | 1 - hw/scsi/vhost-user-scsi.c | 1 - hw/virtio/vdpa-dev.c | 1 - hw/virtio/vhost-user.c | 17 ++++++++--------- hw/virtio/virtio-hmp-cmds.c | 2 -- hw/virtio/virtio-qmp.c | 4 ---- include/hw/virtio/vhost.h | 7 ------- qapi/virtio.json | 3 --- 10 files changed, 22 insertions(+), 41 deletions(-) diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c index c151e83677..dc99de0263 100644 --- a/hw/block/vhost-user-blk.c +++ b/hw/block/vhost-user-blk.c @@ -348,7 +348,6 @@ static int vhost_user_blk_connect(DeviceState *dev, Error **errp) s->dev.nvqs = s->num_queues; s->dev.vqs = s->vhost_vqs; s->dev.vq_index = 0; - s->dev.backend_features = 0; vhost_dev_set_config_notifier(&s->dev, &blk_ops); diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c index 25e9f1fd24..fda90e231e 100644 --- a/hw/net/vhost_net.c +++ b/hw/net/vhost_net.c @@ -52,8 +52,14 @@ int vhost_net_set_config(struct vhost_net *net, const uint8_t *data, void vhost_net_ack_features_ex(struct vhost_net *net, const uint64_t *features) { - virtio_features_copy(net->dev.acked_features_ex, - net->dev.backend_features_ex); + virtio_features_clear(net->dev.acked_features_ex); + if (net->backend == -1) { + net->dev.acked_features = + net->dev.features & (1ULL << VHOST_USER_F_PROTOCOL_FEATURES); + } else if (!qemu_has_vnet_hdr(net->nc)) { + net->dev.acked_features = 1ULL << VHOST_NET_F_VIRTIO_NET_HDR; + } + vhost_ack_features_ex(&net->dev, net->feature_bits, features); } @@ -258,12 +264,9 @@ struct vhost_net *vhost_net_init(VhostNetOptions *options) if (r < 0) { goto fail; } - net->dev.backend_features = qemu_has_vnet_hdr(options->net_backend) - ? 0 : (1ULL << VHOST_NET_F_VIRTIO_NET_HDR); net->backend = r; net->dev.protocol_features = 0; } else { - virtio_features_clear(net->dev.backend_features_ex); net->dev.protocol_features = 0; net->backend = -1; @@ -284,13 +287,12 @@ struct vhost_net *vhost_net_init(VhostNetOptions *options) net->dev.features &= ~(1ULL << VIRTIO_NET_F_MRG_RXBUF); } - if (virtio_features_andnot(missing_features, - net->dev.backend_features_ex, - net->dev.features_ex)) { - fprintf(stderr, "vhost lacks feature mask 0x" VIRTIO_FEATURES_FMT - " for backend\n", VIRTIO_FEATURES_PR(missing_features)); - goto fail; - } + if (!qemu_has_vnet_hdr(options->net_backend) && + (~net->dev.features & (1ULL << VHOST_NET_F_VIRTIO_NET_HDR))) { + fprintf(stderr, "vhost lacks feature mask 0x%llx for backend\n", + ~net->dev.features & (1ULL << VHOST_NET_F_VIRTIO_NET_HDR)); + goto fail; + } } /* Set sane init value. Override when guest acks. */ diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c index 699863cc10..859888fdba 100644 --- a/hw/scsi/vhost-scsi.c +++ b/hw/scsi/vhost-scsi.c @@ -275,7 +275,6 @@ static void vhost_scsi_realize(DeviceState *dev, Error **errp) vqs = g_new0(struct vhost_virtqueue, vsc->dev.nvqs); vsc->dev.vqs = vqs; vsc->dev.vq_index = 0; - vsc->dev.backend_features = 0; ret = vhost_dev_init(&vsc->dev, (void *)(uintptr_t)vhostfd, VHOST_BACKEND_TYPE_KERNEL, 0, errp); diff --git a/hw/scsi/vhost-user-scsi.c b/hw/scsi/vhost-user-scsi.c index 3612897d4b..5070178dc2 100644 --- a/hw/scsi/vhost-user-scsi.c +++ b/hw/scsi/vhost-user-scsi.c @@ -159,7 +159,6 @@ static int vhost_user_scsi_connect(DeviceState *dev, Error **errp) vsc->dev.nvqs = VIRTIO_SCSI_VQ_NUM_FIXED + vs->conf.num_queues; vsc->dev.vqs = s->vhost_vqs; vsc->dev.vq_index = 0; - vsc->dev.backend_features = 0; ret = vhost_dev_init(&vsc->dev, &s->vhost_user, VHOST_BACKEND_TYPE_USER, 0, errp); diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c index 4532d63653..06179e402e 100644 --- a/hw/virtio/vdpa-dev.c +++ b/hw/virtio/vdpa-dev.c @@ -104,7 +104,6 @@ static void vhost_vdpa_device_realize(DeviceState *dev, Error **errp) v->dev.vqs = vqs; v->dev.vq_index = 0; v->dev.vq_index_end = v->dev.nvqs; - v->dev.backend_features = 0; v->started = false; ret = vhost_vdpa_get_iova_range(v->vhostfd, &iova_range); diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index 3ffb6af19f..e21013f2ca 100644 --- a/hw/virtio/vhost-user.c +++ b/hw/virtio/vhost-user.c @@ -1470,14 +1470,15 @@ static int vhost_user_set_features(struct vhost_dev *dev, int ret; /* - * We need to include any extra backend only feature bits that - * might be needed by our device. Currently this includes the - * VHOST_USER_F_PROTOCOL_FEATURES bit for enabling protocol - * features. + * Don't lose VHOST_USER_F_PROTOCOL_FEATURES, which is vhost-user + * specific. */ - ret = vhost_user_set_u64(dev, VHOST_USER_SET_FEATURES, - features | dev->backend_features, - log_enabled); + if (virtio_has_feature(dev->features, VHOST_USER_F_PROTOCOL_FEATURES)) { + features |= 1ULL << VHOST_USER_F_PROTOCOL_FEATURES; + } + + ret = vhost_user_set_u64(dev, VHOST_USER_SET_FEATURES, features, + log_enabled); if (virtio_has_feature(dev->protocol_features, VHOST_USER_PROTOCOL_F_STATUS)) { @@ -2197,8 +2198,6 @@ static int vhost_user_backend_init(struct vhost_dev *dev, void *opaque, (dev->config_ops && dev->config_ops->vhost_dev_config_notifier); uint64_t protocol_features; - dev->backend_features |= 1ULL << VHOST_USER_F_PROTOCOL_FEATURES; - err = vhost_user_get_u64(dev, VHOST_USER_GET_PROTOCOL_FEATURES, &protocol_features); if (err < 0) { diff --git a/hw/virtio/virtio-hmp-cmds.c b/hw/virtio/virtio-hmp-cmds.c index 1daae482d3..4bf9a3109d 100644 --- a/hw/virtio/virtio-hmp-cmds.c +++ b/hw/virtio/virtio-hmp-cmds.c @@ -176,8 +176,6 @@ void hmp_virtio_status(Monitor *mon, const QDict *qdict) hmp_virtio_dump_features(mon, s->vhost_dev->features); monitor_printf(mon, " Acked features:\n"); hmp_virtio_dump_features(mon, s->vhost_dev->acked_features); - monitor_printf(mon, " Backend features:\n"); - hmp_virtio_dump_features(mon, s->vhost_dev->backend_features); monitor_printf(mon, " Protocol features:\n"); hmp_virtio_dump_protocols(mon, s->vhost_dev->protocol_features); } diff --git a/hw/virtio/virtio-qmp.c b/hw/virtio/virtio-qmp.c index 968299fda0..916972e331 100644 --- a/hw/virtio/virtio-qmp.c +++ b/hw/virtio/virtio-qmp.c @@ -780,8 +780,6 @@ VirtioStatus *qmp_x_query_virtio_status(const char *path, Error **errp) vdev->guest_features_ex); status->host_features = qmp_decode_features(vdev->device_id, vdev->host_features_ex); - status->backend_features = qmp_decode_features(vdev->device_id, - vdev->backend_features_ex); switch (vdev->device_endian) { case VIRTIO_DEVICE_ENDIAN_LITTLE: @@ -822,8 +820,6 @@ VirtioStatus *qmp_x_query_virtio_status(const char *path, Error **errp) qmp_decode_features(vdev->device_id, hdev->features_ex); status->vhost_dev->acked_features = qmp_decode_features(vdev->device_id, hdev->acked_features_ex); - status->vhost_dev->backend_features = - qmp_decode_features(vdev->device_id, hdev->backend_features_ex); status->vhost_dev->protocol_features = qmp_decode_protocols(hdev->protocol_features); diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h index 3dfec5e15c..e139e05985 100644 --- a/include/hw/virtio/vhost.h +++ b/include/hw/virtio/vhost.h @@ -100,16 +100,9 @@ struct vhost_dev { * * @features: available features provided by the backend * @acked_features: final negotiated features with front-end driver - * - * @backend_features: this is used in a couple of places to either - * store VHOST_USER_F_PROTOCOL_FEATURES to apply to - * VHOST_USER_SET_FEATURES or VHOST_NET_F_VIRTIO_NET_HDR. Its - * future use should be discouraged and the variable retired as - * its easy to confuse with the VirtIO backend_features. */ VIRTIO_DECLARE_FEATURES(features); VIRTIO_DECLARE_FEATURES(acked_features); - VIRTIO_DECLARE_FEATURES(backend_features); /** * @protocol_features: is the vhost-user only feature set by diff --git a/qapi/virtio.json b/qapi/virtio.json index cd67c4f52e..53ddc6b6a4 100644 --- a/qapi/virtio.json +++ b/qapi/virtio.json @@ -85,8 +85,6 @@ # # @acked-features: vhost_dev acked_features # -# @backend-features: vhost_dev backend_features -# # @protocol-features: vhost_dev protocol_features # # @max-queues: vhost_dev max_queues @@ -106,7 +104,6 @@ 'vq-index': 'int', 'features': 'VirtioDeviceFeatures', 'acked-features': 'VirtioDeviceFeatures', - 'backend-features': 'VirtioDeviceFeatures', 'protocol-features': 'VhostDeviceProtocols', 'max-queues': 'uint64', 'backend-cap': 'uint64', -- 2.52.0

1 0

[PATCH v2 0/7] virtio-iommu: Support setting aw-bits and granule
by Michal Privoznik 06 Feb '26

06 Feb '26

v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3HN6… diff to v1: - setting of granule is done in a subelement of driver now Michal Prívozník (7): conf: Teach virDomainParseMemory() new retval qemu_capabilities: Introduce QEMU_CAPS_VIRTIO_IOMMU_AW_BITS conf: Allow aw_bits for virtio-iommu qemu_command: Generate aw_bits prop for virtio-iommu conf: Introduce granule attribute for virtio-iommu qemu_validate: Check whether granule of virtio-iommu is supported qemu_command: Generate granule prop for virtio-iommu docs/formatdomain.rst | 40 +++++++- src/conf/domain_conf.c | 95 +++++++++++++++++-- src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 21 +++- src/conf/schemas/domaincommon.rng | 22 +++++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 11 +++ src/qemu/qemu_validate.c | 30 +++++- .../caps_10.0.0_aarch64.xml | 1 + .../caps_10.0.0_ppc64.xml | 1 + .../caps_10.0.0_s390x.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.xml | 1 + .../caps_10.1.0_s390x.xml | 1 + .../caps_10.1.0_x86_64+inteltdx.xml | 1 + .../caps_10.1.0_x86_64.xml | 1 + .../caps_10.2.0_aarch64.xml | 1 + .../caps_10.2.0_x86_64+mshv.xml | 1 + .../caps_10.2.0_x86_64.xml | 1 + .../caps_11.0.0_aarch64.xml | 1 + .../caps_11.0.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_riscv64.xml | 1 + .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 1 + .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_aarch64+hvf.xml | 1 + .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.xml | 1 + .../virtio-iommu-aarch64.aarch64-latest.args | 2 +- .../virtio-iommu-aarch64.aarch64-latest.xml | 3 + .../qemuxmlconfdata/virtio-iommu-aarch64.xml | 6 +- ...io-iommu-dma-translation.x86_64-latest.err | 2 +- .../virtio-iommu-x86_64.x86_64-latest.args | 2 +- .../virtio-iommu-x86_64.x86_64-latest.xml | 3 + tests/qemuxmlconfdata/virtio-iommu-x86_64.xml | 6 +- 37 files changed, 247 insertions(+), 21 deletions(-) -- 2.52.0

2 11

[PATCH v10 0/8] blockdev-replace
by Vladimir Sementsov-Ogievskiy 05 Feb '26

05 Feb '26

Hi all! This series presents a new command blockdev-replace, which helps to insert/remove filters anywhere in the block graph. It can: - replace qdev block-node by qdev-id - replace export block-node by export-id - replace any child of parent block-node by node-name and child name So insertions is done in two steps: 1. blockdev_add (create filter node, unparented) [some parent] [new filter] | | V V [ some child ] 2. blockdev-replace (replace child by the filter) [some parent] | V [new filter] | V [some child] And removal is done in reverse order: 1. blockdev-replace (go back to picture 1) 2. blockdev_del (remove filter node) Ideally, we should do both operations (add + replace or replace + del) in a transaction, but that should be another series. v10: reabsed on master. 02: change exp-blk check into assert 04: rewrite to simpler API (on unique parent id) 07: switch to new API 08: new Vladimir Sementsov-Ogievskiy (8): block-backend: blk_root(): drop const specifier on return type block/export: add blk_by_export_id() block: make bdrv_find_child() function public qapi: add blockdev-replace command block: bdrv_get_xdbg_block_graph(): report export ids iotests.py: introduce VM.assert_edges_list() method iotests: add filter-insertion deprecate names duplication between qdev, block-node and block-export block.c | 29 +++ block/block-backend.c | 2 +- block/export/export.c | 41 ++++ blockdev.c | 82 +++++-- docs/about/deprecated.rst | 10 + include/block/block-global-state.h | 1 + include/block/block_int-io.h | 2 + include/block/export.h | 1 + include/system/block-backend-global-state.h | 5 +- qapi/block-core.json | 24 ++ stubs/blk-by-qdev-id.c | 18 ++ stubs/blk-exp-find-by-blk.c | 13 + stubs/meson.build | 2 + system/qdev-monitor.c | 16 ++ tests/qemu-iotests/iotests.py | 17 ++ tests/qemu-iotests/tests/filter-insertion | 222 ++++++++++++++++++ tests/qemu-iotests/tests/filter-insertion.out | 5 + 17 files changed, 474 insertions(+), 16 deletions(-) create mode 100644 stubs/blk-by-qdev-id.c create mode 100644 stubs/blk-exp-find-by-blk.c create mode 100755 tests/qemu-iotests/tests/filter-insertion create mode 100644 tests/qemu-iotests/tests/filter-insertion.out -- 2.52.0

2 13

Failed to find parent device on Arrow Lake processor
by Bertrand Leconte 04 Feb '26

04 Feb '26

Hello, I am using libvirt within Qubes OS (https://www.qubes-or.org) My laptop is a Lenovo P16 Gen 3 with an Intel Core Ultra 9 275HX, which is in the Arrow Lake family. The associated PCH is an Intel 800 Series WM880. The particularity of this platform is that the PCH includes a dedicated PCI Root Complex in addition to the CPU one. That means that I have devices connected to `0000:00` bus (addresses like 0000:00:xx.x) and devices connected to `0000:80` bus (addresses like 0000:80:xx.x). The consequence of that architecture is that there is no PCI Root Port serving the `0000:80` bus. When I want to PCI passthrough my USB controller device `0000:80:14.0`, the function `virPCIDeviceIsBehindSwitchLackingACS()` says that `Failed to find parent device for 0000:80:14.0`. When I look into the source code, it looks like it enumerates all PCI devices, searching for the Root Port managing the bus `0000:80`. As I said before, it cannot find any as it's A Root Complex that manage the `0000:80` bus and not a Root Port (a Root Complex it's not a PCI/PCIe device). However, for any device connected to PCI bus `0000:00`, it cannot find any PCI Root Port either but there is an exception in the code for it. @Bloged (one of Qubes OS users) proposed in https://forum.qubes-os.org/t/aistone-x6ar57ty-aka-tongfang-x6-16-intel-high… to change the code to diff --git a/src/util/virpci.c b/src/util/virpci.c index 3816369..fbed8f5 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -2555,12 +2555,20 @@ virPCIDeviceIsBehindSwitchLackingACS(virPCIDevice *dev) 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, and this is a root-like bus (0 or 0x80), + * ACS doesn't come into play since devices on these buses can't P2P + * without going through the root IOMMU. + * + * Arrow Lake (Intel Core Ultra 200 series) uses bus 0x80 for integrated + * devices like USB controllers, with a complex PCH topology that confuses + * parent device detection. Treat bus 0x80 like bus 0 for ACS purposes. */ if (dev->address.bus == 0) { return 0; + } else if (dev->address.bus == 0x80) { + VIR_DEBUG("%s %s: Arrow Lake bus 0x80 device, treating as root bus for ACS check", + dev->id, dev->name); + return 0; } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to find parent device for %1$s"), -- This patch works, but it does not look very generic. In addition to that, a thread in 2017 (this mailing list) seems to indicate that this part of the code may not be necessary: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/QRI4…. My question: can someone that knows this part of the code have a look to see what is the best way to correct it: either propose a patch to `virPCIDeviceIsBehindSwitchLackingACS` that is more generic or to change the rest of the code so it's no more used? (By the way, internationalization of error messages in syslog/dmesg/journald does not look like a good idea. It is very hard to understand if the message is given in French in this mailing list…) Thanks very much for your help Bertrand

6 14