Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]