Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

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/254ca48a67779ccf9b9f60e2bb5796a305c03f95.camel@infradead.org/
... and the GICD_IIDR thing which I reposted today:
https://lore.kernel.org/all/20260511113558.3325004-2-dwmw2@infradead.org/

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]