Re: [PULL v2 09/30] virtio-mmio: fix QUEUE_NUM_MAX

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jul 29, 2026 at 12:25:30PM +0300, Michael Tokarev wrote:
> On 7/29/26 08:12, Michael Tokarev wrote:
> > On 7/29/26 02:22, Michael S. Tsirkin wrote:
> > > On Tue, Jul 28, 2026 at 11:17:34PM +0300, Michael Tokarev wrote:
> > ..
> > > > So this whole change, for older versions, becomes just:
> > > > 
> > > > --- a/hw/virtio/virtio.c
> > > > +++ b/hw/virtio/virtio.c
> > > > @@ -2572,6 +2572,8 @@ VirtQueue *virtio_add_queue(VirtIODevice *vdev, int queue_size,
> > > >       if (i == VIRTIO_QUEUE_MAX || queue_size > VIRTQUEUE_MAX_SIZE)
> > > >           abort();
> > > > 
> > > > +    queue_size = VIRTQUEUE_MAX_SIZE; /* fixed properly in 11.1. */
> > > > +
> > > 
> > > Or you can stick to upstream and add the compat entry for 11.0.
> > 
> > Compat entry for 11.0 which will never be used?
> > With a non-obvious logic which boils down to this single line?
> > 
> > Or what do you mean?
> > 
> > BTW, can't this logic be implemented without a compat property in
> > the first place?  This x-override-queue-size seems like a hack.
> > or a.. twisted way to compare a machine version.
> > 
> > Can't this very place become
> > 
> >     if (machine_version < 11.1) {
> >        queue_size = VIRTQUEUE_MAX_SIZE;
> >     }
> > 
> > instead of using this indirect property?
> 
> Michael, I still don't understand what we're doing here and - now -
> why do we need to distinguish between old and new machine types at all.
> 
> Behavior before the fixes:
> 
>  qemu always reported queue size to be the maximum allowed one (1024),
>    even if actual queue size requested and allocated was smaller
>  qemu accepted requests to elements past the allocated size, which
>    allowed to read/write past the allocated buffer - which can't be
>    considered part of ABI, obviously :)
> 
> Behavior after the fixes, for new machine types:
> 
>  qemu reports actually requested and allocated queue size
>  qemu properly disallows access past the allocated queue size
> 
> What would break if we switch to the new behavior unconditionally,
> regardless of the machine types?

It's guest visible. You will get two reads from same register
suddenly returning different values.


> I don't understand why do you suggest to implement the same logic for
> older/stable qemu versions if it will always evaluate to allocating
> the max size for the queue regardless of the requested size.
> 
> Thanks,
> 
> /mjt

My preference, normally, is to just stick to upstream as much as
possibly. I just do not want slightly different code bases when we can
trivially have one.  If nothing else, less of a chance a follow up patch
will cause conflicts, and then it snowballs from there.


-- 
MST