On 7/26/25 1:52 PM, Akihiko Odaki wrote: > On 2025/07/24 4:31, Paolo Abeni wrote: >> @@ -1477,6 +1509,13 @@ int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy, >> return virtio_pci_add_mem_cap(proxy, &cap.cap); >> } >> >> +static int virtio_pci_select_max(const VirtIODevice *vdev) >> +{ >> + return virtio_features_use_ex(vdev->host_features_ex) ? >> + VIRTIO_FEATURES_NU32S : >> + 2; > > This function could be simplified by replacing VIRTIO_FEATURES_NU32S > without any functional difference: > > 1. For writes: virtio_set_features_ex() already ignores extended > features when !virtio_features_use_ex(vdev->host_features_ex) > 2. For reads: When !virtio_features_use_ex(vdev->host_features_ex), the > upper bits of host_features_ex are zero, and guest_features upper bits > remain zero (since they can't be set per point 1) > > So the conditional logic is redundant here.
This is to satisfy a request from Jason: https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg05291.html https://lists.gnu.org/archive/html/qemu-devel/2025-07/msg05423.html I agree there will not be functional differences always accessing the full space, but the guest could still be able to notice, i.e. the extended space will be zeroed on read with that patched qemu and untouched by the current code and this patch. To be on the safe side I think it would be better to avoid such difference, as suggested by Jason. Does the above make sense to you? Thanks, Paolo