On Fri, 2026-04-24 at 12:07 +0100, Marc Zyngier wrote: > On Tue, 07 Apr 2026 21:27:02 +0100, David Woodhouse wrote: > > The uaccess write handlers for GICD_IIDR in both GICv2 and GICv3 > > extract the revision field from 'reg' (the current IIDR value read back > > from the emulated distributor) instead of 'val' (the value userspace is > > trying to write). This means userspace can never actually change the > > implementation revision — the extracted value is always the current one. > > > > Fix the FIELD_GET to use 'val' so that userspace can select a different > > revision for migration compatibility. > > > > [...] > > Applied to fixes, thanks! > > [1/3] KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value > commit: a0e6ae45af17e8b27958830595799c702ffbab8d
There was a v2 of this series which also cleaned up the weird inconsistency of the IIDR value with the actual behaviour, and which fixed the fact that it's currently not possible to maintain guest compatibility when upgrading from a pre-d53c2c29ae0d kernel to a new one — despite the fact that that kind of compatibility is *precisely* what the revision field in the IIDR is designed for. https://lore.kernel.org/all/[email protected]/
smime.p7s
Description: S/MIME cryptographic signature
