On Tue, 19 May 2026 13:13:41 +0100, Paolo Bonzini <[email protected]> wrote: > > On Tue, May 19, 2026 at 1:44 PM David Woodhouse <[email protected]> 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/[email protected]/ > 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.
