[PATCH] arm64: kernel: disable CNP on Carmel

On NVIDIA Carmel cores, CNP behaves differently than it does on standard
ARM cores. On Carmel, if two cores have CNP enabled and share an L2 TLB
entry created by core0 for a specific ASID, a non-shareable TLBI from
core1 may still see the shared entry. On standard ARM cores, that TLBI
will invalidate the shared entry as well.

This causes issues with patchsets that attempt to do local TLBIs based
on cpumasks instead of broadcast TLBIs. Avoid these issues by disabling
CNP support for NVIDIA Carmel cores.

Signed-off-by: Rich Wiley <redacted>
---
 arch/arm64/kernel/cpufeature.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9fac745aa7bb..2aa38a430f6a 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c

@@ -986,6 +986,12 @@ static bool has_cache_dic(const struct arm64_cpu_capabilities *entry,
 	return ctr & BIT(CTR_DIC_SHIFT);
 }
 
+static bool cpu_has_broken_cnp(void)
+{
+	const struct midr_range range = MIDR_ALL_VERSIONS(MIDR_NVIDIA_CARMEL);
+	return is_midr_in_range(read_cpuid_id(), &range);
+}
+
 static bool __maybe_unused
 has_useable_cnp(const struct arm64_cpu_capabilities *entry, int scope)
 {

@@ -994,7 +1000,10 @@ has_useable_cnp(const struct arm64_cpu_capabilities *entry, int scope)
 	 * may share TLB entries with a CPU stuck in the crashed
 	 * kernel.
 	 */
-	 if (is_kdump_kernel())
+	if (is_kdump_kernel())
+		return false;
+
+	if (cpu_has_broken_cnp())
 		return false;
 
 	return has_cpuid_feature(entry, scope);

-- 
2.17.1


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

Hi Rich,

On 2/17/21 7:01 AM, Rich Wiley wrote:

On NVIDIA Carmel cores, CNP behaves differently than it does on standard
ARM cores. On Carmel, if two cores have CNP enabled and share an L2 TLB
entry created by core0 for a specific ASID, a non-shareable TLBI from
core1 may still see the shared entry. On standard ARM cores, that TLBI
will invalidate the shared entry as well.

Could you please explain more on "may still see the shared entry" on the
NVIDIA Carmel core vs "invalid the shared entry" on standard ARM core.

This causes issues with patchsets that attempt to do local TLBIs based

A new patchset ? Does it impact any existing functionality ? What sort of
issues this create ?

on cpumasks instead of broadcast TLBIs. Avoid these issues by disabling

Does it affect all existing local TLBI which iterate over cpumask or are
there some particular situations ? The problem description here needs to
be more clear and specific.

CNP support for NVIDIA Carmel cores.

- Anshuman

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

On Wed, Feb 17, 2021 at 10:43:52AM +0530, Anshuman Khandual wrote:

On 2/17/21 7:01 AM, Rich Wiley wrote:

quoted

On NVIDIA Carmel cores, CNP behaves differently than it does on standard
ARM cores. On Carmel, if two cores have CNP enabled and share an L2 TLB
entry created by core0 for a specific ASID, a non-shareable TLBI from
core1 may still see the shared entry. On standard ARM cores, that TLBI
will invalidate the shared entry as well.

Could you please explain more on "may still see the shared entry" on the
NVIDIA Carmel core vs "invalid the shared entry" on standard ARM core.

That's about the CnP feature where more than one core can share the same
TLB.

quoted

This causes issues with patchsets that attempt to do local TLBIs based

A new patchset ? Does it impact any existing functionality ? What sort of
issues this create ?

quoted

on cpumasks instead of broadcast TLBIs. Avoid these issues by disabling

Does it affect all existing local TLBI which iterate over cpumask or are
there some particular situations ? The problem description here needs to
be more clear and specific.

Local TLBI does not work as described in the ARM ARM w.r.t. CnP, so CnP
needs disabling.

-- 
Catalin

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

On Tue, Feb 16, 2021 at 05:31:51PM -0800, Rich Wiley wrote:

Since this is a CPU erratum, can you please implement it as other errata
workarounds we have in the kernel? You'd need to provide an erratum
number for this CPU as well. You could make the .capability definition
of the erratum entry more generic like ARM64_WORKAROUND_BROKEN_CNP.

Thanks.

-- 
Catalin

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

On Wed, Feb 17, 2021 at 11:25:12AM +0000, Catalin Marinas wrote:

On Tue, Feb 16, 2021 at 05:31:51PM -0800, Rich Wiley wrote:

quoted

On NVIDIA Carmel cores, CNP behaves differently than it does on standard
ARM cores. On Carmel, if two cores have CNP enabled and share an L2 TLB
entry created by core0 for a specific ASID, a non-shareable TLBI from
core1 may still see the shared entry. On standard ARM cores, that TLBI
will invalidate the shared entry as well.

This causes issues with patchsets that attempt to do local TLBIs based
on cpumasks instead of broadcast TLBIs. Avoid these issues by disabling
CNP support for NVIDIA Carmel cores.

Signed-off-by: Rich Wiley <redacted>
---
 arch/arm64/kernel/cpufeature.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9fac745aa7bb..2aa38a430f6a 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c

@@ -986,6 +986,12 @@ static bool has_cache_dic(const struct arm64_cpu_capabilities *entry,
 	return ctr & BIT(CTR_DIC_SHIFT);
 }
 
+static bool cpu_has_broken_cnp(void)
+{
+	const struct midr_range range = MIDR_ALL_VERSIONS(MIDR_NVIDIA_CARMEL);
+	return is_midr_in_range(read_cpuid_id(), &range);
+}

Since this is a CPU erratum, can you please implement it as other errata
workarounds we have in the kernel? You'd need to provide an erratum
number for this CPU as well. You could make the .capability definition
of the erratum entry more generic like ARM64_WORKAROUND_BROKEN_CNP.

Yes, and please include an update to Documentation/arm64/silicon-errata.rst

Will

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