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

On Wed, Jul 29, 2026 at 08:24:22AM +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. */
> 
> BTW, with this override in place, the second half of this fix isn't
> even needed - for older/stable versions, this line is enough to fix
> CVE-2026-50626.
> 
> > 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.
> 
> Besides being a hack, it also redefines a #define within a compat property
> (using a "magic number" instead of a symbolic constant) in a non-obvious
> way.  Though it might be a good way here, since the property value is the
> actual historical number which should never be changed.
> 
> > Can't this very place become
> > 
> >     if (machine_version < 11.1) {
> >        queue_size = VIRTQUEUE_MAX_SIZE;
> >     }
> > 
> > instead of using this indirect property?
> 
> That would be great if this patch can be reduced to this (plus the
> fixup for VIRTIO_MMIO_QUEUE_NUM_MAX in virtio_mmio_read) without
> (ab)using properties like this.
> 
> BTW, isn't x-override-queue-size becoming a part of user interface?

I guess you dislike how qemu handles compatibility generally?


> Thanks,
> 
> /mjt