[PATCH 1/2] arm64: Add part number for Arm Cortex-A77

[PATCH 1/2] arm64: Add part number for Arm Cortex-A77

[Rob Herring]

Add the MIDR part number info for the Arm Cortex-A77.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
 arch/arm64/include/asm/cputype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index a87a93f67671..7a2d3c336579 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -71,6 +71,7 @@
 #define ARM_CPU_PART_CORTEX_A55		0xD05
 #define ARM_CPU_PART_CORTEX_A76		0xD0B
 #define ARM_CPU_PART_NEOVERSE_N1	0xD0C
+#define ARM_CPU_PART_CORTEX_A77		0xD0D
 
 #define APM_CPU_PART_POTENZA		0x000
 
@@ -104,6 +105,7 @@
 #define MIDR_CORTEX_A55 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A55)
 #define MIDR_CORTEX_A76	MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A76)
 #define MIDR_NEOVERSE_N1 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N1)
+#define MIDR_CORTEX_A77	MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A77)
 #define MIDR_THUNDERX	MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
 #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
 #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
-- 
2.25.1

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH 2/2] arm64: Add workaround for Arm Cortex-A77 erratum 1508412

[Rob Herring]

On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device load
and a store exclusive or PAR_EL1 read can cause a deadlock.

The workaround requires a DMB SY before and after a PAR_EL1 register read
and the disabling of KVM. KVM must be disabled to prevent the problematic
sequence in guests' EL1. This workaround also depends on a firmware
counterpart to enable the h/w to insert DMB SY after load and store
exclusive instructions. See the errata document SDEN-1152370 v10 [1] for
more information.

All the other PAR_EL1 reads besides the one in
is_spurious_el1_translation_fault() are in KVM code, so the work-around is
not needed for them.

[1] https://static.docs.arm.com/101992/0010/Arm_Cortex_A77_MP074_Software_Developer_Errata_Notice_v10.pdf

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Rob Herring <robh@kernel.org>
---
 Documentation/arm64/silicon-errata.rst |  2 ++
 arch/arm64/Kconfig                     | 16 ++++++++++++++++
 arch/arm64/include/asm/cpucaps.h       |  3 ++-
 arch/arm64/kernel/cpu_errata.c         | 10 ++++++++++
 arch/arm64/kvm/arm.c                   |  5 +++++
 arch/arm64/mm/fault.c                  | 10 ++++++++++
 6 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
index 936cf2a59ca4..716b279e3b33 100644
--- a/Documentation/arm64/silicon-errata.rst
+++ b/Documentation/arm64/silicon-errata.rst
@@ -90,6 +90,8 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Cortex-A76      | #1463225        | ARM64_ERRATUM_1463225       |
 +----------------+-----------------+-----------------+-----------------------------+
+| ARM            | Cortex-A77      | #1508412        | ARM64_ERRATUM_1508412       |
++----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Neoverse-N1     | #1188873,1418040| ARM64_ERRATUM_1418040       |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Neoverse-N1     | #1349291        | N/A                         |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 31380da53689..b6edf07d2a17 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -626,6 +626,22 @@ config ARM64_ERRATUM_1542419
 
 	  If unsure, say Y.
 
+config ARM64_ERRATUM_1508412
+	bool "Cortex-A77: 1508412: workaround deadlock on sequence of NC/Device load and store exclusive or PAR read"
+	default y
+	help
+	  This option adds a workaround for Arm Cortex-A77 erratum 1508412.
+
+	  Affected Cortex-A77 cores (r0p0, r1p0) could deadlock on a sequence
+	  of a store-exclusive or read of PAR_EL1 and a load with device or
+	  non-cacheable memory attributes. The workaround depends on a firmware
+	  counterpart.
+
+	  Workaround the issue by inserting DMB SY barriers around PAR_EL1
+	  register reads and disabling KVM support.
+
+	  If unsure, say Y.
+
 config CAVIUM_ERRATUM_22375
 	bool "Cavium erratum 22375, 24313"
 	default y
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index d7b3bb0cb180..2a2cdb4ced8b 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -62,7 +62,8 @@
 #define ARM64_HAS_GENERIC_AUTH			52
 #define ARM64_HAS_32BIT_EL1			53
 #define ARM64_BTI				54
+#define ARM64_WORKAROUND_1508412		55
 
-#define ARM64_NCAPS				55
+#define ARM64_NCAPS				56
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index ad06d6802d2e..5eee8a75540c 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -938,6 +938,16 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 		.matches = has_neoverse_n1_erratum_1542419,
 		.cpu_enable = cpu_enable_trap_ctr_access,
 	},
+#endif
+#ifdef CONFIG_ARM64_ERRATUM_1508412
+	{
+		/* we depend on the firmware portion for correctness */
+		.desc = "ARM erratum 1508412 (kernel portion)",
+		.capability = ARM64_WORKAROUND_1508412,
+		ERRATA_MIDR_RANGE(MIDR_CORTEX_A77,
+				  0, 0,
+				  1, 0),
+	},
 #endif
 	{
 	}
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 90cb90561446..4caa58f0e103 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1653,6 +1653,11 @@ int kvm_arch_init(void *opaque)
 		return -ENODEV;
 	}
 
+	if (cpus_have_const_cap(ARM64_WORKAROUND_1508412)) {
+		kvm_info("not available due to erratum 1508412\n");
+		return -ENODEV;
+	}
+
 	for_each_online_cpu(cpu) {
 		smp_call_function_single(cpu, check_kvm_target_cpu, &ret, 1);
 		if (ret < 0) {
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 8afb238ff335..d599d60f06fd 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -260,7 +260,17 @@ static bool __kprobes is_spurious_el1_translation_fault(unsigned long addr,
 	local_irq_save(flags);
 	asm volatile("at s1e1r, %0" :: "r" (addr));
 	isb();
+	/*
+	 * Arm Errata 1508412 requires dmb(sy) before and after reads of
+	 * PAR_EL1.
+	 * As this location is not a hot path, just condition it on the config
+	 * option.
+	 */
+	if (IS_ENABLED(CONFIG_ARM64_ERRATUM_1508412))
+		dmb(sy);
 	par = read_sysreg(par_el1);
+	if (IS_ENABLED(CONFIG_ARM64_ERRATUM_1508412))
+		dmb(sy);
 	local_irq_restore(flags);
 
 	/*
-- 
2.25.1

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 2/2] arm64: Add workaround for Arm Cortex-A77 erratum 1508412

[Marc Zyngier]

Hi Rob,

On 2020-06-29 22:33, Rob Herring wrote:
> On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device 
> load
> and a store exclusive or PAR_EL1 read can cause a deadlock.
> 
> The workaround requires a DMB SY before and after a PAR_EL1 register 
> read
> and the disabling of KVM. KVM must be disabled to prevent the 
> problematic
> sequence in guests' EL1. This workaround also depends on a firmware
> counterpart to enable the h/w to insert DMB SY after load and store
> exclusive instructions. See the errata document SDEN-1152370 v10 [1] 
> for
> more information.
> 

This seems a bit extreme. Given that this CPU is most likely
used in big-little systems, there is still a bunch of CPUs
on which we could reliably execute guests. It is also likely
that people could run trusted guests.

I would suggest printing a big fat warning and taining the
kernel with TAINT_CPU_OUT_OF_SPEC, together with the required
DSBs in the KVM code.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 2/2] arm64: Add workaround for Arm Cortex-A77 erratum 1508412

[Will Deacon]

[+Jose]

On Tue, Jun 30, 2020 at 09:15:15AM +0100, Marc Zyngier wrote:
> On 2020-06-29 22:33, Rob Herring wrote:
> > On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device
> > load
> > and a store exclusive or PAR_EL1 read can cause a deadlock.
> > 
> > The workaround requires a DMB SY before and after a PAR_EL1 register
> > read
> > and the disabling of KVM. KVM must be disabled to prevent the
> > problematic
> > sequence in guests' EL1. This workaround also depends on a firmware
> > counterpart to enable the h/w to insert DMB SY after load and store
> > exclusive instructions. See the errata document SDEN-1152370 v10 [1] for
> > more information.

Jose -- having an SMC interface to see if the firmware is holding up its
side of the bargian would be really helpful here. There's been one in
development for _months_ now; any update?

> This seems a bit extreme. Given that this CPU is most likely
> used in big-little systems, there is still a bunch of CPUs
> on which we could reliably execute guests. It is also likely
> that people could run trusted guests.
> 
> I would suggest printing a big fat warning and taining the
> kernel with TAINT_CPU_OUT_OF_SPEC, together with the required
> DSBs in the KVM code.

Honestly, I think a TAINT is pointless here and we shouldn't be in the
business of trying to police what people do with their systems when there's
absolutely nothing we can do to help them. After all, they can always
disable KVM themselves if they want to. The only sensible action you can
take on seeing the taint is to disable the workaround to get rid of it,
which is also the worst thing you can do! As another example, imagine if
we had the ability to detect whether or not firmware was setting the patch
registers. If we knew that it wasn't applying the workaround, would we
TAINT on entering userspace? I don't think so. We'd probably just print a
message when trying to apply the workaround, indicating that it was
incomplete and the system may deadlock.

Finally, we have another erratum that allows guests to deadlock the system
(Cortex-A57 832075) so ultimately it's up to the person deploying the system
to decide whether or not they can tolerate the risk of deadlock. In many
cases, it won't be an issue, but if it is and they require KVM, then the
part is dead in the water and Linux can't help with that.

Will
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 2/2] arm64: Add workaround for Arm Cortex-A77 erratum 1508412

[James Morse]

Hi guys,

On 30/06/2020 09:36, Will Deacon wrote:
> On Tue, Jun 30, 2020 at 09:15:15AM +0100, Marc Zyngier wrote:
>> On 2020-06-29 22:33, Rob Herring wrote:
>>> On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device
>>> load
>>> and a store exclusive or PAR_EL1 read can cause a deadlock.
>>>
>>> The workaround requires a DMB SY before and after a PAR_EL1 register
>>> read
>>> and the disabling of KVM. KVM must be disabled to prevent the
>>> problematic
>>> sequence in guests' EL1. This workaround also depends on a firmware
>>> counterpart to enable the h/w to insert DMB SY after load and store
>>> exclusive instructions. See the errata document SDEN-1152370 v10 [1] for
>>> more information.
> 
> Jose -- having an SMC interface to see if the firmware is holding up its
> side of the bargian would be really helpful here. There's been one in
> development for _months_ now; any update?
> 
>> This seems a bit extreme. Given that this CPU is most likely
>> used in big-little systems, there is still a bunch of CPUs
>> on which we could reliably execute guests.

(I'm guessing you don't want KVM to second guess the scheduler's placement on big.little
systems?)


>> It is also likely that people could run trusted guests.

Knowing whether the user trusts the guest not to tickle this is the piece of information
that would change what we do here.


>> I would suggest printing a big fat warning and taining the
>> kernel with TAINT_CPU_OUT_OF_SPEC, together with the required
>> DSBs in the KVM code.
> 
> Honestly, I think a TAINT is pointless here and we shouldn't be in the
> business of trying to police what people do with their systems when there's
> absolutely nothing we can do to help them. After all, they can always
> disable KVM themselves if they want to. The only sensible action you can
> take on seeing the taint is to disable the workaround to get rid of it,
> which is also the worst thing you can do! As another example, imagine if
> we had the ability to detect whether or not firmware was setting the patch
> registers. If we knew that it wasn't applying the workaround, would we
> TAINT on entering userspace? I don't think so. We'd probably just print a
> message when trying to apply the workaround, indicating that it was
> incomplete and the system may deadlock.
> 
> Finally, we have another erratum that allows guests to deadlock the system
> (Cortex-A57 832075)

Aha! Precedent.

We don't print any warning about untrusted guests in that case.


> so ultimately it's up to the person deploying the system
> to decide whether or not they can tolerate the risk of deadlock. In many
> cases, it won't be an issue, but if it is and they require KVM, then the
> part is dead in the water and Linux can't help with that.

Sure. So the plan here is to add the barriers around KVMs PAR_EL1 accesses, and get KVM to
print a warning that this platform is only suitable for trusted guests? (and do that for
A57's 832075 too).
As its a deadlock, not the guest influence/corrupting the host, I think this is fine. Not
printing a warning implies we hope anyone deploying KVM on affected silicon has read the
errata document...


Thanks,

James
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm