On Wed, 2026-05-20 at 10:47 -0700, Oliver Upton wrote: > On Wed, May 20, 2026 at 12:33:52AM +0100, David Woodhouse wrote: > > On Tue, 2026-05-19 at 15:57 -0700, Oliver Upton wrote: > > > What ifs and maybes do not meet the bar, in my opinion, for preserving > > > bug emulation in KVM. Of course there could be a little flexibility with > > > that but we need to have some way of discriminating between bug fixes > > > and genuine guest expectations around the behavior of virtual hardware. > > > > I believe you have this completely backwards. > > No, I really don't. > > Leaving every bugfix that could _possibly_ have a guest-visible impact > subject to drive-by scrutiny many years after the dust has settled is > not an acceptable working dynamic. Especially since it would appear > that the rest of the ecosystem has long since moved on from this > particular issue.
That's reductio ad absurdum. I can continue to work around this one internally, sure. But I'm also concerned about the general case because not only did you refuse it, but you *also* said that this change in guest-visible behaviour "should've happened without a change to the revision number". Which seems to indicate that not only are you being randomly obstructive about a one-line fix, you *also* don't actually understand the general concept of what is expected of KVM, which this Documentation patch is intending to clarify. It was *right* to bump the IIDR from 1 to 2 when this guest visible behaviour was changed. The only problem was not letting userspace select the old revision. I'm really concerned that we now appear to have a regression of understanding of even the part we previously *did* get right. > If this matters to you so deeply then please, be part of the solution > instead. You may find that reviewing patches leads to better outcomes > than getting belligerent with the arm64 folks every time you guys > decide to rebase your kernel. Hell, hypotheticals actually have a lot > more weight in the context of a review. And if your testing is extensive > enough to catch these sort of subtleties, don't you think it's better > done against mainline? Yes. Definitely. That's why my series with the fixes is more *test* than actual fix, giving a nice simple framework for any such changes in future. It checks that GICR_CTLR_IR|GICR_CTLR_CES are visible only with IIDR.rev=3 for example. And we're making progress on the amount of downstream crap, but it doesn't help when we seem to have an impedance mismatch on the very question of what it means to support customers on KVM at scale. This thread is not exactly encouraging my engineers to poke their heads above the parapet. > Maybe it's just me but I am left feeling disappointed that we all > haven't found a productive way of working together. I've tried to bridge > the gap here; we obviously need to do something that at least fixes the > UAPI breakage. Although apparently we don't even care to meet that low > of bar. > > > A stable and mature platform doesn't get to play in its ivory tower and > > randomly inflict breakage on guests because they "deserve it". > > Really? Aren't you asking for us to emulate something completely broken > for you? No. I'm asking for a path to be able to *fix* it. As things stand, if I just drop these patches and launch guests on a new kernel, those guests will see writable IGROUPR registers and may try to use them. And then if I have to roll *back* a kernel deployment, those guests may lose interrupts. The *only* time a guest-visible feature (or bugfix, nobody cares about the difference outside the ivory tower) can be enabled is when the kernel deployment is finished and stable and *won't* be rolled back. And *then* new launches (and reboots) can get it. And one day, when the last guest which was launched *without* it is finally rebooted and sees the new model, *then* maybe we no longer need that one line if() statement to support IIDR version 1. 2018 was basically *yesterday*. And I'm kind of scared that I even have to explain it.
smime.p7s
Description: S/MIME cryptographic signature
