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

[Marc Zyngier <maz@kernel.org>]

On Wed, 08 Apr 2026 09:39:15 +0100,
"Woodhouse, David" <dwmw@amazon.co.uk> wrote:
> 
> [1  <multipart/signed (en-US) (7bit)>]
> [1.1  <text/plain; UTF-8 (quoted-printable)>]
> 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?

That's your problem. KVM/arm64 never supported downgrading.

Not to mention that there is no valid GIC implementation that has RO
group registers. All you are doing is to inflict a hypervisor bug on
unsuspecting guests, for no good reason.

> 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?

A guest that doesn't configures the groups cannot expect anything to
work. You'd have the exact same problem on bare-metal.

> 
> > 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 :)

That's hardly an argument, is it?

	M.

-- 
Without deviation from the norm, progress is not possible.