On Wed, Jul 29, 2026 at 12:49:59PM +0300, Michael Tokarev wrote: > 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.
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. > 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? Yes you will find we do that a lot. See for example x-pci-express-writeable-slt-bug there were many more we just dropped support for the affected machine types. > 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). Of course if it was like this we would have noticed much earlier. FYI most guests configure exactly the size we specify as max. The state is in guest memory, so it just works. For the typical scenario (no in-order), and no attempts to fill all of the queue with a single request, things simply work with a slightly bigger queue. Maybe a bit higher memory requirement, that is all. 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. > > > 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? They just need to look at the upstream commit and it's clear. 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. > 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 A discussion for upstream, imho. -- MST
