Re: [PATCH v3 06/13] arm64: cpufeature: Detect E2H0 not being implemented

From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v3 06/13] arm64: cpufeature: Detect E2H0 not being implemented
Date: Tue, 09 Jan 2024 15:16:13 +0000	[thread overview]
Message-ID: <868r4ya66a.wl-maz@kernel.org> (raw)
In-Reply-To: <20231211124238.GB25277@willie-the-truck>

On Mon, 11 Dec 2023 12:42:38 +0000,
Will Deacon <will@kernel.org> wrote:
> 
> On Mon, Nov 27, 2023 at 11:45:52AM +0000, Marc Zyngier wrote:
> > FEAT_E2H0 is a new feature that indicates whether or not HCR_EL2.E2H
> > can be set to 0. Amusingly, this feature is set to 0 when implemented,
> > and otherwise negative.
> > 
> > Add a new capability and detection infrastructure to detect the
> > absence of FEAT_E2H0.
> > 
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/kernel/cpufeature.c | 7 +++++++
> >  arch/arm64/tools/cpucaps       | 1 +
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 4a72fb26daec..6ef9811f7bb7 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2786,6 +2786,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> >  		.matches = has_cpuid_feature,
> >  		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP)
> >  	},
> > +	{
> > +		.desc = "FEAT_E2H0 not implemented",
> > +		.capability = ARM64_HCR_E2H_RES1,
> > +		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> 
> Is ARM64_CPUCAP_SYSTEM_FEATURE the right thing to use here? For example,
> if the boot CPUs have this feature but a late CPU doesn't, then I think
> we should be ok as long as we're using VHE, but I don't think the above
> takes that into account.
> 
> Maybe we shouldn't be adding new capabilities for this at all, and instead
> just look at the sanitised register value when we need to?

That's probably good enough for this particular use of E2H0, as this
is not used on any fast path.

However, when E2H0 is 0b1110 (NV1 being RES0, and thus the guest's own
HCR_EL2.E2H being RES1), we need to sanitise the guest's HCR_EL2 no
matter what the guest writes there.

With that in mind, __vcpu_el2_e2h_is_set() using the sanitised value
would result in a binary search on a lot of very hot paths, something
that I'm keen to avoid.

So while I'm happy to drop this particular cap, I'll keep the one
introduced in patch #6.

Thanks,

	M.

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

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