Re: [PATCH 2/3] KVM: arm64: vgic: Allow userspace to set IIDR revision 1

Woodhouse, David
2026-04-08T08:39:20Z

[-- Attachment #1.1: Type: text/plain, Size: 2128 bytes --]

On Wed, 2026-04-08 at 08:54 +0100, Marc Zyngier wrote:
> On Tue, 07 Apr 2026 21:27:03 +0100,
> David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > Allow userspace to select GICD_IIDR revision 1, which restores the
> > original pre-d53c2c29ae0d ("KVM: arm/arm64: vgic: Allow configuration
> > of interrupt groups") behaviour where interrupt groups are not
> > guest-configurable.
>
> I'm a bit surprised by this.
>
> Either your guest knows that the group registers are not writable and
> already deals with the buggy behaviour by not configuring the groups
> (or configuring them in a way that matches what the implementation
> does). Or it configures them differently and totally fails to handle
> the interrupts as they are delivered using the wrong exception type,
> if at all.
>
> I'd expect that your guests fall in the former category and not the
> latter, as we'd be discussing a very different problem. And my vague
> recollection of this issue is that we had established that as long as
> the reset values were unchanged, there was no harm in letting things
> rip.

What if the guest boots under a new host kernel and finds the group
registers are writable, and then is live migrated to an old host kernel
on which they are not?

What about hibernation, if the *boot* kernel in the guest configures
the groups, but then transfers control back to the resumed guest kernel
which had not?

> So what is this *really* fixing?

I look at that question the other way round.

KVM has an established procedure for allowing userspace to control
guest-visible changes, using the IIDR. First the host kernel which
*supports* the change is rolled out, and only then does the VMM start
to enable it for new launches.

Even if we can address the questions above, and even if we can convince
ourselves that those are the *only* questions to ask... why not follow
the normal, safe, procedure? Especially given that there is already an
IIDR value which corresponds to it.

We don't *have* to YOLO it... and I don't want to :)

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

[-- Attachment #2.1: Type: text/plain, Size: 215 bytes --]

Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.

[-- Attachment #2.2: Type: text/html, Size: 228 bytes --]