Re: [RFC PATCH v4 07/14] virtio-pci: implement support for extended features

[Paolo Abeni <pabeni@redhat.com>]

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