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

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

On Thu, Jul 30, 2026 at 08:38:46AM +0300, Michael Tokarev wrote:
> On 7/29/26 13:26, Michael S. Tsirkin wrote:
> > On Wed, Jul 29, 2026 at 12:49:59PM +0300, Michael Tokarev wrote:
> 
> > > The old value basically makes no sense.  We returned a wrong value
> > > here, now we return the correct one.
> > 
> > So now, guest read the big value, and it is writing that value back.
> > But since we changed the value to smaller one now guest is
> > writing a value bigger than the max and out of spec and it will fail.
> > Not nice at all.
> 
> Just to clarify: this might happen only after migration (to qemu "fixed"
> the way I was thinking).

read num before migration, write after migration.

> []
> > I'm not strongly objecting to changing the original patch.
> > This needs a bunch of thought though, as we are breaking a
> > fundamental promise of live migration.
> > And given we are in freeze and it's a CVE, there's some urgency
> > to get the fix merged.
> 
> Yes, I fully understand the time constraints we have here.  Also,
> it's fixed for 11.1+, and the release is coming - and once it's
> out, this whole problem is history already :)
> 
> [...]
> 
> > My suggestion would be to propose a cleanup upstream, including
> > an analysis of the risks, and we'll discuss.
> > 
> > Or you can do original development in the stable branch if you
> > prefer, be my guest, but don't expect it to get same level of
> > scrutiny as upstream code gets. If anything breaks, it's on you.
> 
> There's no need for a stable-only solution which is different in
> logic, since it is the upstream version with current logic which
> we must be able to migrate to anyway.  So any changes needs to be
> in agreement with the upstream.
> 
> > > Ofc it would be ideal - from the back-porting PoV only - to just
> > > drop this all entirely and unconditionally report the correct
> > > queue size to begin with, as per above.
> 
> > A discussion for upstream, imho.
> 
> Yes, this is exactly what I'm doing - discussing it here.
> But without a proposal yet ;))
> 
> Ok.
> 
> For now, for the two active stable series, I'll pick up only this
> change out of the two, and even it reduced to a one-liner I mentioned
> earlier (doing `queue_size = QUEUE_SIZE_MAX`).  This is sufficient to
> fix the bug in stable series (the other change isn't needed).  If
> anything will come touching this place (including a more elegant
> solution), it's trivial to revert it and re-do, no snow-ball effect
> is expected.
> 
> And thank you for your patience!
> 
> /mjt