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: Thu, 2 May 2024 15:40:38 +0100	[thread overview]
Message-ID: <ZjOl5hwU7yPXk8gs@shell.armlinux.org.uk> (raw)
In-Reply-To: <ZjKRBcAML5T6cm4q@linux.dev>

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

I think the only two ways around this would be to:

1) teach QEMU about the contents of these registers, with which fields
   in these registers can be ignored when reloading a VMs context.

2) allow userspace to write to the XNX field such that it can be set
   to values seen with previous kernels (thus allowing at least one-
   way migration.)

(1) has the advantage that reloading a VM state on older vs newer
kernels can work in either direction, whereas (2) would only work
for state saved on an older kernel loaded onto a newer kernel.

I've been bitten before with KVM differences between kernel versions
in the past - where the number of registers that userspace sees has
changed despite being on the same hardware. I'm now wondering what
testing goes on to validate this part of the UAPI across different
kernel versions on the same hardware.

Surely, given the impact of these changing value (a failure of VMs),
we should be aware whenever any of these registers are different from
one kernel to another on the same hardware?

It's fine if all one cares about is starting fresh VMs on each host
kernel reboot, but any use case beyond that seems to be fragile.

I did knock up a test program that dumped the list of registers so
that one could trivially diff the output between various kernels.
Maybe I need to extend that to dump the register values themselves,
and then maybe we need to find a way to get some kind of automated
testing setup to highlight differences. (something maybe kernelci
could add?)

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