February 2026 - Devel - libvirt List Archives

[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 0/3] apparmor: Separate seclabel generation and profile loading
by Michal Privoznik 04 Feb '26

04 Feb '26

See 3/3 for explanation. Michal Prívozník (3): security: Introduce virSecurityDomainLoadProfile() qemu: Call virSecurityManagerLoadProfile() at the end of qemuProcessPrepareDomain() security_apparmor: Move profile loading into .domainLoadProfile callback src/libvirt_private.syms | 1 + src/qemu/qemu_process.c | 7 +++++++ src/qemu/qemu_security.h | 1 + src/security/security_apparmor.c | 31 +++++++++++++++++++++++-------- src/security/security_driver.h | 4 ++++ src/security/security_manager.c | 13 +++++++++++++ src/security/security_manager.h | 2 ++ src/security/security_stack.c | 15 +++++++++++++++ 8 files changed, 66 insertions(+), 8 deletions(-) -- 2.52.0

2 4

Download of volume: alternating frames of 262120 and 24 bytes
by Erik Huelsmann 03 Feb '26

03 Feb '26

Hi, While analysing traffic generated by "virsh vol-download", I noticed that the download stream exhibits the following pattern (over qemu+ssh://): <Start> Read 4 bytes (= frame length field) Read 262144 bytes (= header + payload ; VIR_NET_MESSAGE_HEADER_MAX (24) + VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX (262120)) Read 4 bytes (= frame length field) Read 48 bytes (= header + payload) <Go back to Start> While nothing seems to be actually wrong with this pattern, the average payload on large data transfers is only (262120+24)/2 == 131072 and the CPU makes double the iterations necessary. I'll be trying to figure out where this comes from, but I imagine that will be pretty hard to track down. Two questions: 1. Do you see the same thing? 2. Any ideas/hints where I could start looking? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 8

[PATCH v2 0/2] bhyve: improve loader handling on arm64
by Roman Bogorodskiy 03 Feb '26

03 Feb '26

Changes since v1: - Make the default loader uboot path configurable in bhyve.conf. It might be useful for users and also way simpler to mock in the test than the hardcoded value in the code. Roman Bogorodskiy (2): bhyve: improve loader handling on arm64 bhyve: conf: do not hardcode datadir in bhyve.conf src/bhyve/{bhyve.conf => bhyve.conf.in} | 7 +++++- src/bhyve/bhyve_conf.c | 8 +++++++ src/bhyve/bhyve_domain.c | 23 +++++++++++++++++++ src/bhyve/bhyve_utils.h | 2 ++ src/bhyve/meson.build | 13 +++++++++-- .../aarch64/bhyvexml2argv-base.args | 1 + .../aarch64/bhyvexml2argv-base.ldargs | 8 +------ .../aarch64/bhyvexml2argv-console.args | 1 + .../aarch64/bhyvexml2argv-console.ldargs | 8 +------ tests/bhyvexml2argvmock.c | 20 +++++++++++++++- tests/bhyvexml2argvtest.c | 2 ++ .../aarch64/bhyvexml2xmlout-base.xml | 1 + .../aarch64/bhyvexml2xmlout-console.xml | 1 + tests/bhyvexml2xmltest.c | 4 ++++ 14 files changed, 81 insertions(+), 18 deletions(-) rename src/bhyve/{bhyve.conf => bhyve.conf.in} (73%) -- 2.52.0

2 6

[PATCH 0/9] bhyve: A couple of memleak fixes
by Michal Privoznik 03 Feb '26

03 Feb '26

*** BLURB HERE *** Michal Prívozník (9): bhyve: Avoid memleak in bhyveParsePassthru() bhyve: Avoid leaking @addrs in bhyveDomainAssignPCIAddresses() bhyve_command: Avoid leaking @buf in virBhyveProcessBuildBhyveCmd() bhyve_command: Avoid memleak in bhyveBuildNetArgStr() bhyvexml2argvmock: Provide virCPUProbeHost() bhyvexml2argvtest: Avoid leaking driver caps bhyvexml2argvtest: Don't leak parts of driver config bhyvexml2argvtest: Avoid leaking firmwareDir bhyvexml2xmltest: Avoid leaking driver caps src/bhyve/bhyve_command.c | 26 ++++++++++++-------------- src/bhyve/bhyve_device.c | 10 +++++++--- src/bhyve/bhyve_parse_command.c | 2 +- tests/bhyvexml2argvmock.c | 8 ++++++++ tests/bhyvexml2argvtest.c | 10 +++++++--- tests/bhyvexml2xmltest.c | 1 + 6 files changed, 36 insertions(+), 21 deletions(-) -- 2.52.0

2 10

[PATCH] rpcgen: Pass XDRPROC_T_3ARGS to test_demo.c
by Michal Privoznik 03 Feb '26

03 Feb '26

From: Michal Privoznik <mprivozn(a)redhat.com> In previous commit of v12.0.0-85-g2c66b6d72c we've tried to solve a problem where xdrproc_t is a prototype of a function which takes only two arguments instead of three. See original commit for more info. The fix consists of a config time check and setting XDRPROC_T_3ARGS accordingly (in meson-config.h). This works for nearly all of our code, except rpcgen which is intentionally independent of the rest of the code. Therefore, the macro has to be set extra - by specifying it on the compiler cmd line. Fixes: 2c66b6d72cd48d3cf80f957f55cfb1548feb46c4 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- scripts/rpcgen/tests/meson.build | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/rpcgen/tests/meson.build b/scripts/rpcgen/tests/meson.build index 057a61433d..4df7471a99 100644 --- a/scripts/rpcgen/tests/meson.build +++ b/scripts/rpcgen/tests/meson.build @@ -4,13 +4,17 @@ rpcgen_tests = files([ 'test_parser.py', ]) +xdrproc_flags = [] +if conf.has('XDRPROC_T_3ARGS') + xdrproc_flags += [ '-DXDRPROC_T_3ARGS' ] +endif test_demo = executable( 'test_demo', [ 'test_demo.c' ], c_args: [ '-Dabs_srcdir="@0@"'.format(meson.current_source_dir()), - ] + cc_flags_relaxed_frame_limit, + ] + cc_flags_relaxed_frame_limit + xdrproc_flags, dependencies: [ xdr_dep, glib_dep ], -- 2.52.0

3 2

[PATCH] build: add detection of xdrproc_t arguments count
by Roman Bogorodskiy 03 Feb '26

03 Feb '26

According to 9fa3a8ab6fd82ad2f5a14b490696085061418718, macOS insists on passing 3 arguments for xdrproc_t. Passing 3 arguments was a good common ground, but since recently[1] FreeBSD only accepts 2 arguments. Add a meson.build check whether 3 arguments are accepted, and add macros which passes either 2 or 3 arguments to xdrproc_t based on the result of this check. 1: https://cgit.freebsd.org/src/commit/?id=ac5a19ec6989675c8ec6c3ca245dba243d1… Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- meson.build | 19 +++++++++++++++++++ scripts/rpcgen/tests/test_demo.c | 12 +++++++++--- src/rpc/virnetmessage.c | 10 ++++++++-- 3 files changed, 36 insertions(+), 5 deletions(-) diff --git a/meson.build b/meson.build index 964d1fa4e1..4a4f89c1cb 100644 --- a/meson.build +++ b/meson.build @@ -893,6 +893,25 @@ else xdr_dep = dependency('', required: false) endif +if xdr_dep.found() + xdrproc_3arg_code = ''' + #include <rpc/xdr.h> + + bool_t test_filter(XDR *xdr, void *data, unsigned int opaque_flags) { + return TRUE; + } + + int main() { + XDR xdr; + xdrproc_t filter = (xdrproc_t)&test_filter; + (*filter)(&xdr, NULL, 0); + return 0; + } + ''' + if cc.compiles(xdrproc_3arg_code, dependencies: xdr_dep) + conf.set('XDRPROC_T_3ARGS', 1) + endif +endif # generic build dependencies diff --git a/scripts/rpcgen/tests/test_demo.c b/scripts/rpcgen/tests/test_demo.c index e6ba7ddbc5..82eda89592 100644 --- a/scripts/rpcgen/tests/test_demo.c +++ b/scripts/rpcgen/tests/test_demo.c @@ -8,6 +8,12 @@ # define xdr_uint64_t xdr_u_int64_t #endif +#if defined(XDRPROC_T_3ARGS) +# define XDRPROC(proc, xdr, data) (proc(&xdr, data, 0)) +#else +# define XDRPROC(proc, xdr, data) (proc(&xdr, data)) +#endif + #include "demo.h" #include "demo.c" @@ -27,7 +33,7 @@ static void test_xdr(xdrproc_t proc, void *vorig, void *vnew, const char *testna /* Step 1: serialize the vorig and compare to the data in test .bin files */ xdrmem_create(&xdr, buf, buflen, XDR_ENCODE); - ret = !!proc(&xdr, vorig, 0); + ret = !!XDRPROC(proc, xdr, vorig); g_assert_cmpint(ret, ==, !fail); if (fail) @@ -54,7 +60,7 @@ static void test_xdr(xdrproc_t proc, void *vorig, void *vnew, const char *testna /* Step 2: de-serialize the state to create a new object */ xdrmem_create(&xdr, buf, buflen, XDR_DECODE); - ret = !!proc(&xdr, vnew, 0); + ret = !!XDRPROC(proc, xdr, vnew); g_assert_cmpint(ret, ==, true); actlen = xdr_getpos(&xdr); @@ -68,7 +74,7 @@ static void test_xdr(xdrproc_t proc, void *vorig, void *vnew, const char *testna xdrmem_create(&xdr, buf, buflen, XDR_ENCODE); - ret = !!proc(&xdr, vnew, 0); + ret = !!XDRPROC(proc, xdr, vnew); g_assert_cmpint(ret, ==, true); actlen = xdr_getpos(&xdr); diff --git a/src/rpc/virnetmessage.c b/src/rpc/virnetmessage.c index af0f9cb30b..e66df5c9e2 100644 --- a/src/rpc/virnetmessage.c +++ b/src/rpc/virnetmessage.c @@ -34,6 +34,12 @@ VIR_LOG_INIT("rpc.netmessage"); +#if defined(XDRPROC_T_3ARGS) +# define XDRPROC_FILTER(filter, xdr, data) ((*filter)(&xdr, data, 0)) +#else +# define XDRPROC_FILTER(filter, xdr, data) ((*filter)(&xdr, data)) +#endif + virNetMessage *virNetMessageNew(bool tracked) { virNetMessage *msg; @@ -367,7 +373,7 @@ int virNetMessageEncodePayload(virNetMessage *msg, msg->bufferLength - msg->bufferOffset, XDR_ENCODE); /* Try to encode the payload. If the buffer is too small increase it. */ - while (!(*filter)(&xdr, data, 0)) { + while (!XDRPROC_FILTER(*filter, xdr, data)) { unsigned int newlen = msg->bufferLength - VIR_NET_MESSAGE_LEN_MAX; newlen *= 2; @@ -424,7 +430,7 @@ int virNetMessageDecodePayload(virNetMessage *msg, xdrmem_create(&xdr, msg->buffer + msg->bufferOffset, msg->bufferLength - msg->bufferOffset, XDR_DECODE); - if (!(*filter)(&xdr, data, 0)) { + if (!XDRPROC_FILTER(*filter, xdr, data)) { virReportError(VIR_ERR_RPC, "%s", _("Unable to decode message payload")); goto error; } -- 2.52.0

4 7