Date: Wed, 1 May 2024 17:44:57 +0000
From: Oliver Upton <oliver.upton@linux.dev>
To: Will Deacon <will@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH 1/2] KVM: arm64: Fix hvhe/nvhe early alias parsing
Message-ID: <ZjJ_mdsCa_fAy_NT@linux.dev>
References: <20240501163400.15838-1-will@kernel.org>
 <20240501163400.15838-2-will@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240501163400.15838-2-will@kernel.org>

On Wed, May 01, 2024 at 05:33:59PM +0100, Will Deacon wrote:
> Booting a kernel with "arm64_sw.hvhe=1 kvm-arm.mode=nvhe" on the
> command-line results in KVM initialising using hVHE, whereas one might
> expect the latter option to override the former.
> 
> Fix this by adding "arm64_sw.hvhe=0" to the alias expansion for
> "kvm-arm.mode=nvhe".

Hmm, I wonder if it'd be better to just evaluate the sanitised VH field
in hvhe_possible(). Otherwise I worry about keeping aliases in sync when
new command line options come along.

This is similar to what we had before commit 35876f35f482 ("arm64:
cpufeature: Add helper to test for CPU feature overrides") w/ the added
use of the sanitised reg.

Thoughts?

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 56583677c1f2..3bd5f00a8db3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2138,6 +2138,12 @@ static bool has_nested_virt_support(const struct arm64_cpu_capabilities *cap,
 static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
 			  int __unused)
 {
+	u64 val = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1);
+
+	/* No VHE? Then no hVHE for you either. */
+	if (!SYS_FIELD_GET(ID_AA64MMFR1_EL1, VH, val))
+		return false;
+
 	return arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_HVHE);
 }
 

-- 
Thanks,
Oliver