On Thu, Oct 20, 2022 at 10:07:12AM +0100, Marc Zyngier wrote:
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index a3959e9f7d55..efac89c4c548 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1932,6 +1932,15 @@ static void cpu_copy_el2regs(const struct arm64_cpu_capabilities *__unused)
> write_sysreg(read_sysreg(tpidr_el1), tpidr_el2);
> }
>
> +static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
> + int __unused)
> +{
> + u64 val;
> +
> + val = arm64_sw_feature_override.val & arm64_sw_feature_override.mask;
> + return cpuid_feature_extract_unsigned_field(val, ARM64_SW_FEATURE_OVERRIDE_HVHE);
> +}
Does this need to test ID_AA64MMFR1_EL1.VH as well? Otherwise I don't
see what would stop us from attempting hVHE on a system with asymmetric
support for VHE, as the software override was only evaluated on the boot
CPU.
> +
> #ifdef CONFIG_ARM64_PAN
> static void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused)
> {
> @@ -2642,6 +2651,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> .matches = has_cpuid_feature,
> .cpu_enable = cpu_trap_el0_impdef,
> },
> + {
> + .desc = "VHE for hypervisor only",
> + .capability = ARM64_KVM_HVHE,
> + .type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE,
> + .matches = hvhe_possible,
> + },
> {},
> };
>
> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index f1c0347ec31a..cee2be85b89b 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -43,6 +43,7 @@ HAS_TLB_RANGE
> HAS_VIRT_HOST_EXTN
> HAS_WFXT
> HW_DBM
> +KVM_HVHE
> KVM_PROTECTED_MODE
> MISMATCHED_CACHE_TYPE
> MTE
> --
> 2.34.1
>
--
Thanks,
Oliver
