On Tue, 2026-05-19 at 12:11 +0100, Will Deacon wrote: > On Tue, May 19, 2026 at 11:41:26AM +0100, David Woodhouse wrote: > > 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? > > Hey, come on. Marc cares more about this stuff than anybody else on the > planet. He's been single-handedly maintaining the tree for the past > couple of releases while Oliver was out and he's on the end of a _lot_ > of patches. I'm only cc'd on a fraction of the KVM/arm64 changes and > it's bedlam.
I certainly wouldn't disagree with any of that. The depth of knowledge and the amount of energy that Marc displays through this work is impressive, and I'm sure we all have an enormous amount of respect for it, and for him. I know I do. Nevertheless, the specific technical decision to reject the simple bug fix linked above is dead wrong. Because the principle under which it was rejected — the idea that KVM has no responsibility to maintain compatibility of guest-visible behaviour from one kernel version to the next — is also dead wrong. 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. Or indeed the standards that we've held for Linux kernel ABIs for the last 35 years.
smime.p7s
Description: S/MIME cryptographic signature
