On Fri, 4 Apr 2025 15:48:49 +0200 David Hildenbrand david@redhat.com wrote:
Sounds good to me! But I'm still a little confused by the "holes". What confuses me is that i can think of at least 2 distinct types of "holes": 1) Holes that can be filled later. The queue conceptually exists, but there is no need to back it with any resources for now because it is dormant (it can be seen a hole in comparison to queues that need to materialize -- vring, notifiers, ...) 2) Holes that can not be filled without resetting the device: i.e. if certain features are not negotiated, then a queue X does not exist, but subsequent queues retain their index.
I think it is not about "negotiated", that might be the wrong terminology.
E.g., in QEMU virtio_balloon_device_realize() we define the virtqueues (virtio_add_queue()) if virtio_has_feature(s->host_features).
That is, it's independent of a feature negotiation (IIUC), it's static for the device -- "host_features"
Is that really "negotiated" or is it "the device offers the feature X" ?
It is offered. And this is precisely why I'm so keen on having a precise wording here.
Usually for compatibility one needs negotiated. Because the feature negotiation is mostly about compatibility. I.e. the driver should be able to say, hey I don't know about that feature, and get compatible behavior. If for example VIRTIO_BALLOON_F_FREE_PAGE_HINT and VIRTIO_BALLOON_F_PAGE_REPORTING are both offered but only VIRTIO_BALLOON_F_PAGE_REPORTING is negotiated. That would make reporting_vq jump to +1 compared to the case where VIRTIO_BALLOON_F_FREE_PAGE_HINT is not offered. Which is IMHO no good, because for the features that the driver is going to reject in most of the cases it should not matter if it was offered or not.
@MST: Please correct me if I'm wrong!
Regards, Halil