Re: [PATCH] arm64: cpufeature: Don't treat granule sizes as strict

From: Suzuki K Poulose <suzuki.poulose@arm•com>
To: will@kernel•org, linux-arm-kernel@lists•infradead.org
Cc: mark.rutland@arm•com, khilman@baylibre•com,
	catalin.marinas@arm•com, maz@kernel•org
Subject: Re: [PATCH] arm64: cpufeature: Don't treat granule sizes as strict
Date: Mon, 12 Aug 2019 16:48:35 +0100	[thread overview]
Message-ID: <aab16eaa-c98e-c489-ed61-a659711277de@arm.com> (raw)
In-Reply-To: <20190812150225.25386-1-will@kernel.org>

Hi Will,

On 08/12/2019 04:02 PM, Will Deacon wrote:
> If a CPU doesn't support the page size for which the kernel is
> configured, then we will complain and refuse to bring it online. For
> secondary CPUs (and the boot CPU on a system booting with EFI), we will
> also print an error identifying the mismatch.
> 
> Consequently, the only time that the cpufeature code can detect a
> granule size mismatch is for a granule other than the one that is
> currently being used. Although we would rather such systems didn't
> exist, we've unfortunately lost that battle and Kevin reports that
> on his amlogic S922X (odroid-n2 board) we end up warning and taining
> with defconfig because 16k pages are not supported by all of the CPUs.
> 
> In such a situation, we don't actually care about the feature mismatch,
> particularly now that KVM only exposes the sanitised view of the CPU
> registers. Treat the granule fields as non-strict and let Kevin run
> without a tainted kernel.

I think it may be a good idea to mention the "KVM sanitised feature reg"
feature as a pre-req for KVM safety in the comment section to alert
people backporting this commit to older kernels.

> 
> Cc: Mark Rutland <mark.rutland@arm•com>
> Cc: Marc Zyngier <maz@kernel•org>
> Cc: Suzuki Poulose <suzuki.poulose@arm•com>
> Cc: Catalin Marinas <catalin.marinas@arm•com>
> Reported-by: Kevin Hilman <khilman@baylibre•com>
> Signed-off-by: Will Deacon <will@kernel•org>
> ---
>   arch/arm64/kernel/cpufeature.c | 14 +++++++++++---
>   1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index d19d14ba9ae4..b1fdc486aed8 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -184,9 +184,17 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
>   };
>   
>   static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
> -	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
> -	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
> -	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
> +	/*
> +	 * We already refuse to boot CPUs that don't support our configured
> +	 * page size, so we can only detect mismatches for a page size other
> +	 * than the one we're currently using. Unfortunately, SoCs like this
> +	 * exist in the wild so, even though we don't like it, we'll have to go
> +	 * along with it and treat them as non-strict.
> +	 */
> +	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
> +	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
> +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),

Eitherway,

Acked-by: Suzuki K Poulose <suzuki.poulose@arm•com>

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