On Thu, 2026-04-09 at 14:45 +0100, Marc Zyngier wrote: > On Wed, 08 Apr 2026 09:39:15 +0100, > "Woodhouse, David" <[email protected]> wrote: > > > > 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.
Again, I don't know why you're saying this. It isn't true, and *can't* be true if KVM/arm64 is going to be anything more than a toy. > 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. It's not about "inflicting a hypervisor bug". It's about preserving the exact same environment that those millions of guests already *have* instead of taking the risk of changing things underneath them. And giving us a *path* to cleanly upgrading for new launches. > > 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? Er... yes, yes really it is an argument. I don't want to randomly inflict a device model change on *running* guests, and when they resume from hibernation, when I can preserve the existing behaviour. It's weird enough that you claim that KVM doesn't support downgrading; now you seem to be claiming that it doesn't support retaining compatibility when *upgrading* either! The ability to set IIDR like this was explicitly *designed* for this purpose, wasn't it? Why on earth would you object to being able to set it to KVM_VGIC_IMP_REV_1?
smime.p7s
Description: S/MIME cryptographic signature
