[PATCH RFC] KVM: arm64: allow ID_MMFR4_EL1 to be writable

[Oliver Upton]

On Wed, May 01, 2024 at 07:08:05PM +0100, Russell King (Oracle) wrote:
> On Wed, May 01, 2024 at 05:57:20PM +0000, Oliver Upton wrote:
> > Hi Russell,
> > 
> > On Wed, May 01, 2024 at 06:06:51PM +0100, Russell King (Oracle) wrote:
> > > Between 5.4 and 5.15, the guests view of HPDS, CnP, XNX and AC2
> > > changed their value on the same Neoverse N1 r3p1 hardware which makes
> > > migrating between these kernels on the host problematical.
> > 
> > It'd be helpful to expand a bit more on how these fields changed, better
> > yet if we can blame it back to a commit. I'm guessing the only direction
> > of migration you care about is old -> new then?
> 
> Yes. For MMFR4_EL1, we see 0 with our 5.4 based kernel, and 0x21110
> with our 5.15 kernel. I've been looking at tracking down which commit
> is responsible but I've come up with nothing that fits.
> 
> The only change I can see is the FTR definition for MMFR4, but this
> always included 4:7 (AC2) which changed 0 -> 1. So... no idea what
> commit caused the change.
> 
> There are a load of other registers that we need sorting, but this
> is just a test forray into attempting to solve this.

Got it, let me see if I can find it then. Do share that list of
problematic registers when you have it, hopefully this isn't the tip of
the iceberg...

> > 
> > > We already permit changing HPDS in AA64MMFR1_EL1 and CnP in
> > > AA64MMFR2_EL1. We also allow LSM as we allow that in AA64MMFR2_EL1,
> > > so this patch includes support for that even though it isn't required.
> > > 
> > > Discussing with Marc Zygnier, AC2 should also be fine to be writable,
> > 
> > typo: Zyngier
> > 
> > > even though we don't inject an UNDEF if the guest accesses those
> > > registers.
> > > 
> > > The only questionable one is XNX, execute-never control distinction,
> > > which is also in AA64MMFR1_EL1 but we don't allow to be changed there.
> > 
> > It is quite odd for us to expose this field to non-nested VMs in the
> > first place, though I suppose we will apply an additional set of
> > restrictions for nested VMs when they come along.
> 
> Yes, it did strike me as odd, since the description seems to imply that
> XNX affects EL2, which the VM wouldn't have access to. So I'm not sure
> why we don't just force it to zero.

Probably because we failed to catch it in the first place and setting to
0 now would be even more UAPI breakage. Meh :-/ I don't see any immediate
issues with the patch, especially since it is fixing a genuine UAPI
breakage in KVM.

-- 
Thanks,
Oliver