On Mon, Apr 07 2025, David Hildenbrand david@redhat.com wrote:
On 07.04.25 15:12, Halil Pasic wrote:
On Mon, 7 Apr 2025 04:34:29 -0400 "Michael S. Tsirkin" mst@redhat.com wrote:
On Mon, Apr 07, 2025 at 10:17:10AM +0200, David Hildenbrand wrote:
On 07.04.25 09:52, Michael S. Tsirkin wrote:
On Fri, Apr 04, 2025 at 05:39:10PM +0200, Halil Pasic wrote:
> > Not perfect, but AFAIKS, not horrible.
It is like it is. QEMU does queue exist if the corresponding feature is offered by the device, and that is what we have to live with.
I don't think we can live with this properly though. It means a guest that does not know about some features does not know where to find things.
Please describe a real scenario, I'm missing the point.
OK so.
Device has VIRTIO_BALLOON_F_FREE_PAGE_HINT and VIRTIO_BALLOON_F_REPORTING Driver only knows about VIRTIO_BALLOON_F_REPORTING so it does not know what does VIRTIO_BALLOON_F_FREE_PAGE_HINT do. How does it know which vq to use for reporting? It will try to use the free page hint one.
First, sorry for not catching up again with the discussion earlier.
I think David's point is based on the assumption that by the time feature with the feature bit N+1 is specified and allocates a queue Q, all queues with indexes smaller than Q are allocated and possibly associated with features that were previously specified (and probably have feature bits smaller than N+1).
I.e. that we can mandate, even if you don't want to care about other optional features, you have to, because we say so, for the matter of virtqueue existence. And anything in the future, you don't have to care about because the queue index associated with future features is larger than Q, so it does not affect our position.
I think that argument can fall a part if:
- future features reference optional queues defined in the past
- somebody managed to introduce a limbo where a feature is reserved, and they can not decide if they want a queue or not, or make the existence of the queue depend on something else than a feature bit.
Staring at the cross-vmm, including the adding+removing of features and queues that are not in the spec, I am wondering if (in a world with fixed virtqueues)
Feature bits must be reserved before used.
Queue indices must be reserved before used.
It all smells like a problem similar to device IDs ...
Indeed, we need a rule "reserve a feature bit/queue index before using it, even if you do not plan to spec it properly".