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

[Marc Zyngier]

On Thu, 02 May 2024 11:50:10 +0100,
"Russell King (Oracle)" <linux at armlinux.org.uk> wrote:
> 
> 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.

[...]

Using positive or negative logic doesn't really have any impact on the
result. It often is a matter of concisely expressing what is allowed
or not.

There is also the fact that a lot of the KVM code now checks for
"feature downgrade" and enforces it. Construct such as:

	if (!kvm_has_feat(kvm, ID_AA64ISAR0_EL1, TLB, OS))
		kvm->arch.fgu[HFGITR_GROUP] |= (HFGITR_EL2_TLBIRVAALE1OS|
						HFGITR_EL2_TLBIRVALE1OS	|
						HFGITR_EL2_TLBIRVAAE1OS	|
						HFGITR_EL2_TLBIRVAE1OS	|
						HFGITR_EL2_TLBIVAALE1OS	|
						HFGITR_EL2_TLBIVALE1OS	|
						HFGITR_EL2_TLBIVAAE1OS	|
						HFGITR_EL2_TLBIASIDE1OS	|
						HFGITR_EL2_TLBIVAE1OS	|
						HFGITR_EL2_TLBIVMALLE1OS);

use negative logic by expressing what we don't want to enable.

In the end, consistency matters.

	M.

-- 
Without deviation from the norm, progress is not possible.