On Mon, 2026-05-11 at 18:56 +0200, Paolo Bonzini wrote: > On 5/11/26 18:38, David Woodhouse wrote: > > Not *everything* is in CPUID; one recent exception that comes to mind > > is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the > > existing behaviour of older kernels — even when that behaviour doesn't > > make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would > > *advertise* the feature, but not actually *implement* it. Nevertheless, > > that remains the default behaviour of future kernels unless userspace > > explicitly opts in to fully enable (or disable) the feature. > > > > But this documentation update isn't even asking for that compatible-by- > > default behaviour, even though that is the right thing to do. It's only > > asking that it be *possible* to reinstate the old behaviour, for > > userspace that *knows* about the change and explicitly wants to go back > > to the old way to remain compatible. > > Yep, these are the "quirks"---if it's too early for Arm to commit to > that, I guess it's fine. > > However, independent of this patch which I (obviously) believe is a good > idea, I'd like to understand how far it is, assuming 1) no quirks 2) > same CPU host.
It generally works out on arm64, although it's obviously a lot more work than x86 which makes an effort to get this stuff right. When we upgrade the kernel we do a lot of in-guest testing to find the stuff that "broke", like cache reporting: https://lore.kernel.org/all/[email protected]/ ... and the GICD_IIDR thing which I reposted today: https://lore.kernel.org/all/[email protected]/ Those are the ones I came up against recently because someone had just *reverted* the offending commits local in a previous kernel upgrade, and I'm trying to fix it *properly* this time around and not carry the reverts forward for ever. And fix the expectations too, of course. Being told that we shouldn't *expect* to be able to upgrade and roll back the kernel while remaining compatible is... not OK. > By the way, you didn't Cc Marc... Ah crap, I meant to. Thanks for spotting that! I must have screwed up when I combined and dedeuplicated the get_maintainer.pl output with the recipients of the IIDR patch series.
smime.p7s
Description: S/MIME cryptographic signature
