Il mer 13 mag 2026, 15:57 David Woodhouse <[email protected]> ha scritto: > > 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? > > > > https://lore.kernel.org/kvm/[email protected]/ > > is an example of a bug that "no SW can make any reasonable use of". > > I actually believe that the focus on ICEBP was triggered by some weird > gaming software's anti-DRM mechanism, and that it *did* affect actual > guests in the wild? > > But yeah, *fixing* it should not have any adverse effects. That's the > key.
Yep, so "bug for bug" is not it. > > 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. > > How about "once it is in a Linux release and guest visible, and unless > we *know* that changing it in either direction underneath running > guests cannot cause problems". > > > And besides, both miss the point of *configurability* which is the basis of > > it all. > > Hm, configurability *is* the point, I thought. Yes, and configurability goes way beyond bugs/quirks, which are to some extent a red herring. Configurability for example says that "KVM: arm64: vgic: Allow userspace to set IIDR revision 1" shouldn't be controversial at all. > > 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. > > We literally have those mechanisms already. I am not talking about guest-visible changes across save/restore here, but rather about round-trips through userspace. For example, see the effect of KVM_X2APIC_API_USE_32BIT_IDS on KVM_GET/SET_LAPIC: it couldn't be made the default, because userspace expects to take old data returned by KVM_GET_LAPIC and shove it into KVM_SET_LAPIC. Sucks but can't be avoided. > See commit https://git.kernel.org/torvalds/c/49a1a2c70a7f which adds a > new guest-visible feature in revision 3, but allowed userspace to > restore the old behaviour by setting it to revision 2. All my patch above > does, is make it possible to set it to revision 1 as > well. Because https://git.kernel.org/torvalds/c/d53c2c29ae0d previously > changed the behaviour and bumped the default to 2 *without* allowing > userspace to restore the prior behaviour, and we've been carrying a > *revert* of that patch. > > Why would we *not* accept such a patch? Agreed. Even ignoring your revert, there's no reason why any upgrade past 49a1a2c70a7f has to be from after d53c2c29ae0d. > Marc seems terribly insistent that we SHOULD NOT > restore the behaviour that older KVM offered to guests, and we MUST > change it unconditionally underneath running guests, making these > registers writable on upgrade... and reverting them to read-only for > running guests on a rollback. > > And there we do have a very different viewpoint. That's the design decision I mentioned, of not starting the guest configuration from a clean slate. I believe it complicates things because you have to design from the beginning with the ability to rollback to old versions and to potentially detect conflicts introduced by the rollback. This is exactly why KVM_X86_QUIRK_STUFF_FEATURE_MSRS was introduced: "KVM's initialization of feature MSRs during vCPU creation results in a failed save/restore of PERF_CAPABILITIES. If userspace configures the VM to _not_ have a PMU, because KVM initializes the vCPU's PERF_CAPABILITIES, trying to save/restore the non-zero value will be rejected by the destination." (https://lkml.org/lkml/2024/8/2/1032) For Arm, however, it may be too late to change it; if not, I'll happily watch you argue with Marc about it. But even without that, this doc patch (and the idea that "Where a new kernel introduces a guest-visible change, it provides a mechanism for userspace to select the previous behaviour") should be uncontroversial. Paolo
