Re: [PATCH v1 0/2] KVM: arm: Refuse to enable KVM on systems with SME but not FGT

From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	Vincent Donnefort <vdonnefort@google.com>,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH v1 0/2] KVM: arm: Refuse to enable KVM on systems with SME but not FGT
Date: Sat, 29 Oct 2022 12:46:43 +0100	[thread overview]
Message-ID: <8735b6hmxo.wl-maz@kernel.org> (raw)
In-Reply-To: <20221027205246.812586-1-broonie@kernel.org>

On Thu, 27 Oct 2022 21:52:44 +0100,
Mark Brown <broonie@kernel.org> wrote:
> 
> The architecture requires that any system which implements SME also has
> fine grained traps since SME is a v9.2 feature, meaning that v8.7 must be
> implemented, and FGT is mandatory from v8.6. SME relies on fine grained
> traps to control access to SMPRI_EL1 and in nVHE mode to TPIDR2_EL0,
> without traps SMPRI_EL1.Priority and TPIDR2_EL0 can be used as side
> channels. 
> 
> This series adds support for detecting FGT and refuses to allow KVM to
> be used in architecturally invalid configurations which have SME but not
> FGT, without detection the issue presents as faults due to EL2
> attempting to access the FGT registers which isn't obvious to users.
> Currently fine grained traps are only used in nVHE but but a series
> "arm64/sme: Fix SMPRI_EL1 traps for KVM guests" sent along with this
> will add usage for VHE mode too making the issue more pressing.

I think this goes the wrong way around. SME without FGT is invalid,
and yet you keep SME around and device to kill virtualisation support.

I'd rather it is SME that gets disabled when the kernel boots at EL2.
Furthermore, this is only working around a QEMU issue which can be
fixed (as opposed to HW that is forever baked).

To me, it looks like the most reasonable course of action is a mention
in the QEMU release notes that virtualization and SME are currently
incompatible, and that the user needs to chose one or the other.

We had similar issues in the past where QEMU would ignore certain trap
bits (HCR_EL2.TID{1,2,3}), leading to KVM misbehaving. Did we disable
KVM? No, we fixed QEMU instead. This case isn't different.

Thanks,

	M.

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