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

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH RFC] KVM: arm64: allow ID_MMFR4_EL1 to be writable
Date: Wed, 1 May 2024 19:08:05 +0100	[thread overview]
Message-ID: <ZjKFBUXEhwZ7ZmMM@shell.armlinux.org.uk> (raw)
In-Reply-To: <ZjKCgIyWqNKC6TUu@linux.dev>

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.

> 
> > 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.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel