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 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)". 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. 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. > 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.
