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

[David Woodhouse <dwmw2@infradead.org>]

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

On Tue, 2026-05-19 at 13:56 +0100, Marc Zyngier wrote:
> On Tue, 19 May 2026 13:38:57 +0100,
> Marc Zyngier <maz@kernel.org> wrote:
> > 
> > As I said before, I'd be OK with something that would restore IIDR to
> > REV1. But not something that actively breaks the GIC emulation by
> > reintroducing a bug. That's, by construction, dead code that will only
> > bitrot, because there is no SW that can make use of this nonsense.
> 
> I will also add that if we make it a policy to preserve buggy
> behaviours that the guest cannot be relying on, then I question
> whether we should be fixing anything at all.

I think we just have a different understanding of what it practically
means to have behaviour "that the guest cannot be relying on", as in
the examples I just described for the IIDR issue.

> For example, 6.19 fixed a totally buggy behaviour where a guest
> couldn't not have more than (on most HW) 4 interrupts in flight at any
> given time. This was obviously totally bogus, and this was fixed
> unconditionally, as legitimate guests could experience gold-platted
> lock-ups.

And marked with a Fixes: tag and backported to stable, one presumes?

I'm confused that you think this is relevant. Can you contrive a
situation where a guest actually relied on this bug and *survived*,
like the situations I just explained for the IIDR issue?

You can nit-pick my hypotheticals as unlikely — and they are. But if we
always just YOLO it and change guest-visible behaviour on the basis
that it's "unlikely" to break anyone, and there are many such changes
in a given kernel deployment (e.g. from v6.6 to v6.18), then the
cumulative probability of being bitten by one of those "unlikely"
problems approaches 1.

There's a reason we do a *huge* amount of testing of what the guest
sees as we move from one kernel to the next, and back again, and
endeavour to eliminate all those differences.

And once the new kernel *is* deployed and won't be rolled back, of
course, all new launches can get the newer behaviour (and the latest
version of PSCI, etc...)


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