On Fri, 2026-04-24 at 13:24 +0100, David Woodhouse wrote: > 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]/
Is there a reason the rest of these fixes didn't make 7.1?
smime.p7s
Description: S/MIME cryptographic signature
