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

[Russell King (Oracle)]

On Thu, May 02, 2024 at 04:23:10PM +0100, Marc Zyngier wrote:
> 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.

Is that a request to change my patch?

I'm unclear whether anyone wants changes to it.

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