On Tue, 2026-05-19 at 13:38 +0100, Marc Zyngier wrote: > > > But in this case there's an ID register that tells KVM if userspace > > wants the old or the new behavior, independent of whether that old > > behavior is architecturally valid or not. > > But the "old behaviour" makes no sense, and cannot be used by a guest: > > - either the guest doesn't use the alternative interrupt groups, then > it wasn't affected by the bug. That's 100% of the guests. > > - or the guest did try to use the alternative groups, and it *NEVER* > worked, as it wouldn't get any interrupt at all. What is the point > of preserving a "feature" that only results in a non-working guest?
Given how long this bug existed in KVM, it's entirely feasible that some guests *check* for it and refrain from trying to use the alternative groups if the registers aren't actually writable. If such a guest boots on the new kernel and *does* use alternative groups, and then the kernel is rolled back, it breaks. Or some guest configurations which have only ever been tested under KVM could have a bug where they *rely* on the registers not being writable, and write values which are inconsistent with the rest of their configuration. Which breaks the moment those registers become writable. Even in that latter case, when we're hosting customer guests under KVM and we make a change which breaks things, we don't get to tell customers "you deserved it". And those hypothetical cases *do* happen. All of the time. There's a massive zoo of guest operating systems; not just the major players like Linux, FreeBSD and Windows but a whole bunch of embedded home-grown and network appliance kernels. Nobody is claiming that we shouldn't fix any bug ever.
smime.p7s
Description: S/MIME cryptographic signature
