Hi, On 5/13/26 2:43 PM, Paolo Bonzini wrote: > 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.
for info, this qemu series was merged laterly. [PATCH v10 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures <https://lore.kernel.org/all/[email protected]/#r> https://lore.kernel.org/all/[email protected]/#r It brings an infrastructure to mitigate some migration failures accross different kernel versions. Also there is [PATCH v4 00/17] kvm/arm: Introduce a customizable aarch64 KVM host model, under review https://lore.kernel.org/all/[email protected]/ This series aims at beeing able to offer the capacity to set writable ID regs on the host passthrough vcpu model. Thanks Eric > > Overall, even if we may disagree about the details, are we really on > terribly distant grounds, or are we not? > > Paolo >
