On Wed, 08 Apr 2026 09:39:15 +0100,
"Woodhouse, David" <[email protected]> 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 <[email protected]> wrote:
> > >
> > > From: David Woodhouse <[email protected]>
> > >
> > > 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.
