On Wed, 2026-05-13 at 18:24 +0200, Paolo Bonzini wrote: > > > 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.
So where do we go from here? I assume you'll be taking this Documentation patch via the KVM tree? But what about the actual fix at https://lore.kernel.org/all/[email protected]/ This is a simple and unintrusive bug fix to make KVM/arm64 follow the "common sense" requirement that the doc patch codifies, apparently being rejected with the rather bizarre claim that KVM has no *need* to maintain guest-visible compatibility across host kernel changes. 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? Does Arm not actually *care* whether AArch64 is considered a stable and mature platform for KVM hosting? We don't have CONFIG_EXPERIMENTAL any more, do we? Or perhaps we could mark it such. Is CONFIG_STAGING the right thing, for unstable things which might violate the normal maturity expectations of the kernel?
smime.p7s
Description: S/MIME cryptographic signature
