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

[Russell King (Oracle)]

On Wed, May 01, 2024 at 08:51:15PM +0100, Russell King (Oracle) wrote:
> On Wed, May 01, 2024 at 06:59:17PM +0000, Oliver Upton wrote:
> > 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...
> 
> There unfortunately is an iceberg, but hopefully it isn't big enough to
> sink a ship!
> 
> Besides ID_MMFR4_EL1, here are the other differences we've identified.
> Note that these are Oracle's UEK kernels, so based on stable kernel
> branches.
> 
> Register		Field		5.4.x	5.15.x
> ID_PFR0_EL1		CSV2		0	1
> ID_ISAR6_EL1		DP		0	1
> ID_PFR2_EL1		SSBS		0	1
> 			CSV3		0	1
> ID_AA64DFR0_EL1		PMSVer		1	0
> 			DebugVer	8	6
> ID_AA64MMFR1_EL1	XNX		0	1
> ID_AA64MMFR2_EL1	EVT		0	1
> KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2
> 					0x12	0

I'm finding sys_regs.c very unintuitive for working out what we allow
to be written, because it's all coded in negative-logic. By that I mean
the mask values are all ~(what-we-don't-allow) rather than a positive
this-is-what-we-allow. So I've ended up creating a table, looking up
the registers and working out what's read-only and what's read-write.

>From that, I can see (for example) that from the ISAR6_EL1 register,
the field names appear in the AA64ISAR0_EL1 and AA64ISAR1_EL1
registers, and all non-res0 fields are writable. It is therefore my
intention to submit a patch doing this:

-       AA32_ID_SANITISED(ID_ISAR6_EL1),
+       AA32_ID_WRITABLE(ID_ISAR6_EL1, ID_ISAR6_EL1_I8MM |
+                                      ID_ISAR6_EL1_BF16 |
+                                      ID_ISAR6_EL1_SPECRES |
+                                      ID_ISAR6_EL1_SB |
+                                      ID_ISAR6_EL1_FHM |
+                                      ID_ISAR6_EL1_DP |
+                                      ID_ISAR6_EL1_JSCVT),

which, like the MMFR4 patch, uses positive logic for what we allow
to be changed, even though this is equivalent to ~ID_ISAR6_EL1_RES0
which tells us nothing without either looking up in the spec, or
looking at the generated sysreg-defs.h to figure it out.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!