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

Michael Tokarev <[email protected]>
Newsgroups gmane.comp.emulators.qemu.stable,gmane.comp.emulators.qemu
Message-ID <[email protected]>
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).

[]
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.