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

[Marc Zyngier <maz@kernel.org>]

On Tue, 19 May 2026 13:13:41 +0100,
Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On Tue, May 19, 2026 at 1:44 PM David Woodhouse <dwmw2@infradead.org> wrote:
> > > > So... what next? Is one of the other KVM/arm64 maintainers going to
> > > > speak up? Paolo would you consider taking the fixes through your tree
> > > > directly?
> 
> I admit that my knowledge of Arm is really limited, and I do not
> understand which IIDR values have architecturally allowed behaviors
> and which (if any) were made up by KVM; but even if I cannot honestly
> remark on the code or even the approach, a compatibility knob is the
> right thing to have.  That's a userspace API design matter, not an Arm
> or GIC matter.

I agree that we can have the knob -- not having it is a userspace
issue, and I have said that I was OK with preserving the userspace
interface.

> 
> I hope that Marc provides a better explanation of why he believes
> https://lore.kernel.org/all/20260511113558.3325004-2-dwmw2@infradead.org/
> shouldn't be accepted, because I am more than a bit puzzled about
> *why* that patch is being rejected or (in v3) so far ignored. Marc in
> this thread wrote: "If userspace is not a total joke, it will read all
> the ID registers, and configure what it wants to see, assuming it is a
> feature that can be configured (not everything can, because the
> architecture itself is not fully backward compatible)".

This was a more general comment on the full mechanism that we use to
save/restore the state and at the same time configure the feature
set. Which is what the GICD_IIDR does to some extent for the GIC.

> 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 that, re-introducing a behaviour that cannot be used makes zero
sense to me.

> I will certainly take this patch, but I won't override Marc. However
> I'd like to better understand his point of view, because right now I
> just don't get it.

I don't get it either, but for different reasons.

> 
> > If KVM on arm64 doesn't aspire to maintain guest compatibility across
> > host kernel changes — regardless of whether the previous kernel's
> > behaviour was "blessed" by the architecture specification or not — then
> > it does not meet the expectation that we have of KVM implementations in
> > the Linux kernel.
> 
> I agree with the "aspire" wording. Even if it's not going to be 100%
> achievable, KVM *needs* to aspire to maintain both guest compatibility
> and architecture precision. Sometimes it's impossible, sometimes there
> are constraints that require you to trade off one for another (e.g.
> via quirks, or by breaking behavior that no sane guest would have
> cared about). But in general as a maintainer you don't *get* to
> choose.
> 
> Paolo
> 
> > Or indeed the standards that we've held for Linux kernel ABIs for the
> > last 35 years.

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.

	M.

-- 
Without deviation from the norm, progress is not possible.