On 5/13/26 11:24, David Woodhouse wrote:
On Wed, 2026-05-13 at 09:42 +0100, Marc Zyngier 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).
Yes, this is buggy at times, because the combinatorial explosion of
CPU capabilities and supported features makes it pretty hard to test
(and really nobody actually does). But overall, it works, and QEMU is
growing an infrastructure to manage it in a "user friendly" way.
Yes, that is precisely what I'm asking for. I'm prepared to deal with
the fact that KVM/Arm64 is not a stable and mature platform like x86
is, and that userspace has to find all the random changes from one
version to the next, and explicitly pin things down to be compatible.
All I'm asking for is that KVM makes it *possible* to pin things down
to the behaviour of previously released Linux/KVM kernels.
But really, this isn't what David is asking. He's demanding "bug for
bug" compatibility. For that, we have two possible cases:
No, I am not asking you to meet that bar. I merely observed that x86
does and that it would be nice. But we are a *long* way from that.
x86 doesn't do bug-for-bug compatibility, thankfully - we have quirks
but only 11 of them, or about one per year since we started adding them.
We only add quirks, generally speaking, when 1) we change the way file
descriptors are initialized, 2) guests in the wild were relying on it,
or 3) it prevends restoring state saved from an old kernel. Is there
anything else?
So you're asking something not really far from this:
- this is a behaviour that is not allowed by the architecture: we fix
it for good. We do that on every release. Some minor, some much more
visible. And there is no way we will add this sort of "bring the
bugs back" type of behaviours. Specially when it is really obvious
that no SW can make any reasonable use of the defect. We allow
userspace to keep behaving as before, but the guest will not see a
non-compliant behaviour.
... where for example
https://lore.kernel.org/kvm/[email protected]/
is an example of a bug that "no SW can make any reasonable use of".
Marc, this is complete nonsense and you should know better.
Once a behaviour is present in a released version of Linux/KVM, we
can't just declare it "wrong" and unilaterally impose a change in
guest-visible behaviour on *running* guests as a side-effect of a
kernel upgrade.
The criterion for *KVM* to remain compatible is "once it has been in a
released version of the kernel". Not "once it is in the architecture".
That is *also* obviously nonsense though, isn't it (see example above)?
The truth is in the middle, "once it is in the architecture" is likely
too narrow but "once it is in a Linux release" is way too broad. And
besides, both miss the point of *configurability* which is the basis of
it all.
The main difference between x86 and Arm is the default state at
creation; x86 defaults to a blank slate, mostly; and when we didn't do
that, we regretted it later (cue the STUFF_FEATURE_MSRS quirk). It's
too late to change the behavior for Arm, but I think we can agree that
patches such as
https://lore.kernel.org/kvm/[email protected]/
("KVM: arm64: vgic: Allow userspace to set IIDR revision 1") are what
the letter and spirit of this proposal is about.
Marc did not mention having to deal with guests in the wild. Let's
ignore it for now because even defining "guests in the wild" is hard;
and anyway it's not related to the patch that triggered the discussion.
So we have the third case, "restoring state saved from an old kernel".
If this case arises, I do believe that Arm will have to deal with it and
introduce quirks or KVM_GET/SET_REG hacks. Maybe it hasn't happened
yet, lucky you.
Overall, even if we may disagree about the details, are we really on
terribly distant grounds, or are we not?
Paolo
