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

On 7/29/26 12:38, Michael S. Tsirkin wrote:
> On Wed, Jul 29, 2026 at 12:25:30PM +0300, Michael Tokarev wrote:

>> 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.

The old value basically makes no sense.  We returned a wrong value
here, now we return the correct one.  It's like, I don't know, a lot
of fixes in various other areas - when it was a bug in qemu impl. of
some register read which was subsequently corrected - it doesn't need
a compat property to continue returning a wrong/bogus value for old
machines?  I think here, there's no real difference - because the
guest can't access the "extra" space anyway without causing some
unexpected results (usually a crash).

>> 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.

Yes, this is exactly my preference as well.  It is more, I often
pick up some other changes to stable - changes which aren't fixing
anything, - say, some renames or code shuffling around - just to
make the resulting code closer to the master branch, so that
subsequent changes has much more chances to apply cleanly.

In this case I can drop the addition to hw_compat_11_0[] (because
it doesn't exist in 11.0 and before) and keep everything else.
There will be quite some code which boils down to a single line
(queue_size = QUEUE_SIZE_MAX).  Twisted code which does not contain
the main trigger (the property) at all.  This change and the
subsequent change which it fixes - in reality, all these ifs
and conditions would be just useless, but will give someone a
puzzle to solve, wtf is going on here?

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.

Hwell.. :)

/mjt