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? 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 :)
smime.p7s
Description: S/MIME cryptographic signature
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.
