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.

Quoted 5 lines · Rich Wiley

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.

Quoted 1 line

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 1 line

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.

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 <[email protected]>

---
 arch/arm64/kernel/cpufeature.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

arch/arm64/kernel/cpufeature.c +0 -0

index 9fac745aa7bb..2aa38a430f6a 100644

Quoted 23 lines · Rich Wiley

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 <[email protected]>

---
 arch/arm64/kernel/cpufeature.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

arch/arm64/kernel/cpufeature.c +0 -0

index 9fac745aa7bb..2aa38a430f6a 100644
@@ -986,6 +986,12 @@ static bool has_cache_dic(const struct arm64_cpu_capabilities *entry,
 	return ctr & BIT(CTR_DIC_SHIFT);
 }
 

arch/arm64/kernel/cpufeature.c static bool has_cache_dic(const struct arm64_cpu_capabilities *entry, · line 993

Quoted 5 lines

arch/arm64/kernel/cpufeature.c +5 -0

+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.