On Sun, 10 May 2026 22:28:50 +0100,
David Woodhouse <[email protected]> wrote:
>
> [1 <text/plain; UTF-8 (quoted-printable)>]
> 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?
I already explained why these changes are neither necessary (a guest
that used to run still runs) nor desirable (reintroducing bugs we have
fixed is a bad idea).
I have therefore only taken the fix for the bug affecting userspace,
as that was definitely something worth fixing.
M.
--
Without deviation from the norm, progress is not possible.
