* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-25 15:52 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-25 15:52 UTC (permalink / raw)
To: linux-arm-kernel
The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
is triggered, page table entries using the new translation table base
address (BADDR) will be allocated into the TLB using the old ASID. All
circumstances leading to the incorrect ASID being cached in the TLB arise
when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
operation is in the process of performing a translation using the specific
TTBRx_EL1 being written, and the memory operation uses a translation table
descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
ASID is not subject to this erratum because hardware is prohibited from
performing translations from an out-of-context translation regime.
Consider the following pseudo code.
write new BADDR and ASID values to TTBRx_EL1
Replacing the above sequence with the one below will ensure that no TLB
entries with an incorrect ASID are used by software.
write reserved value to TTBRx_EL1[ASID]
ISB
write new value to TTBRx_EL1[BADDR]
ISB
write new value to TTBRx_EL1[ASID]
ISB
When the above sequence is used, page table entries using the new BADDR
value may still be incorrectly allocated into the TLB using the reserved
ASID. Yet this will not reduce functionality, since TLB entries incorrectly
tagged with the reserved ASID will never be hit by a later instruction.
Based on work by Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 11 +++++++++++
arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/mmu_context.h | 8 +++++++-
arch/arm64/kernel/cpu_errata.c | 7 +++++++
arch/arm64/mm/context.c | 11 +++++++++++
arch/arm64/mm/proc.S | 1 +
8 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 405da11fc3e4..e090415a97d3 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -63,3 +63,4 @@ stable kernels.
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
| | | | |
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+| Qualcomm | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 111742126897..366c7d4d1cc5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -479,6 +479,17 @@ config CAVIUM_ERRATUM_27456
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_1003
+ bool "Falkor E1003: Incorrect translation due to ASID change"
+ default y
+ help
+ On Falkor v1, an incorrect ASID may be cached in the TLB when ASID
+ and BADDR are changed together in TTBRx_EL1. The workaround for this
+ issue is to use a reserved ASID in cpu_do_switch_mm() before
+ switching to the new ASID.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 3a4301163e04..1b67c3782d00 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -25,6 +25,7 @@
#include <asm/asm-offsets.h>
#include <asm/cpufeature.h>
+#include <asm/mmu_context.h>
#include <asm/page.h>
#include <asm/pgtable-hwdef.h>
#include <asm/ptrace.h>
@@ -441,6 +442,28 @@ alternative_endif
.endm
/*
+ * Errata workaround prior to TTBR0_EL1 update
+ *
+ * val: TTBR value with new BADDR, preserved
+ * tmp0: temporary register, clobbered
+ * tmp1: other temporary register, clobbered
+ */
+ .macro pre_ttbr0_update_workaround, val, tmp0, tmp1
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
+ mrs \tmp0, ttbr0_el1
+ mov \tmp1, #FALKOR_RESERVED_ASID
+ bfi \tmp0, \tmp1, #48, #16 // reserved ASID + old BADDR
+ msr ttbr0_el1, \tmp0
+ isb
+ bfi \tmp0, \val, #0, #48 // reserved ASID + new BADDR
+ msr ttbr0_el1, \tmp0
+ isb
+alternative_else_nop_endif
+#endif
+ .endm
+
+/*
* Errata workaround post TTBR0_EL1 update.
*/
.macro post_ttbr0_update_workaround
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 4174f09678c4..5aaf7eede432 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -35,7 +35,8 @@
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
#define ARM64_HAS_NO_FPSIMD 16
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 17
-#define ARM64_NCAPS 17
+#define ARM64_NCAPS 18
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 0363fe80455c..9632b0508037 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -19,6 +19,10 @@
#ifndef __ASM_MMU_CONTEXT_H
#define __ASM_MMU_CONTEXT_H
+#define FALKOR_RESERVED_ASID 1
+
+#ifndef __ASSEMBLY__
+
#include <linux/compiler.h>
#include <linux/sched.h>
@@ -220,4 +224,6 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
void verify_cpu_asid_bits(void);
-#endif
+#endif /* !__ASSEMBLY__ */
+
+#endif /* !__ASM_MMU_CONTEXT_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index b75e917aac46..787b5422c559 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -130,6 +130,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
.def_scope = SCOPE_LOCAL_CPU,
.enable = cpu_enable_trap_ctr_access,
},
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
+ {
+ .desc = "Qualcomm Falkor erratum 1003",
+ .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1003,
+ MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
+ },
+#endif
{
}
};
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 4c63cb154859..67df38184903 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -79,6 +79,13 @@ void verify_cpu_asid_bits(void)
}
}
+static void set_reserved_asid_bits(void)
+{
+ if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_1003) &&
+ cpus_have_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
+ __set_bit(FALKOR_RESERVED_ASID, asid_map);
+}
+
static void flush_context(unsigned int cpu)
{
int i;
@@ -87,6 +94,8 @@ static void flush_context(unsigned int cpu)
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
+ set_reserved_asid_bits();
+
/*
* Ensure the generation bump is observed before we xchg the
* active_asids.
@@ -244,6 +253,8 @@ static int asids_init(void)
panic("Failed to allocate bitmap for %lu ASIDs\n",
NUM_USER_ASIDS);
+ set_reserved_asid_bits();
+
pr_info("ASID allocator initialised with %lu entries\n", NUM_USER_ASIDS);
return 0;
}
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 32682be978e0..cd4d53d7e458 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -138,6 +138,7 @@ ENDPROC(cpu_do_resume)
* - pgd_phys - physical address of new TTB
*/
ENTRY(cpu_do_switch_mm)
+ pre_ttbr0_update_workaround x0, x1, x2
mmid x1, x1 // get mm->context.id
bfi x0, x1, #48, #16 // set the ASID
msr ttbr0_el1, x0 // set TTBR0
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-25 15:52 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-25 15:52 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
kvm, linux-arm-kernel, kvmarm, linux-kernel, shankerd, timur,
Jonathan Corbet, linux-doc
Cc: Jon Masters, Neil Leeder, Mark Langsdorf
The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
is triggered, page table entries using the new translation table base
address (BADDR) will be allocated into the TLB using the old ASID. All
circumstances leading to the incorrect ASID being cached in the TLB arise
when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
operation is in the process of performing a translation using the specific
TTBRx_EL1 being written, and the memory operation uses a translation table
descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
ASID is not subject to this erratum because hardware is prohibited from
performing translations from an out-of-context translation regime.
Consider the following pseudo code.
write new BADDR and ASID values to TTBRx_EL1
Replacing the above sequence with the one below will ensure that no TLB
entries with an incorrect ASID are used by software.
write reserved value to TTBRx_EL1[ASID]
ISB
write new value to TTBRx_EL1[BADDR]
ISB
write new value to TTBRx_EL1[ASID]
ISB
When the above sequence is used, page table entries using the new BADDR
value may still be incorrectly allocated into the TLB using the reserved
ASID. Yet this will not reduce functionality, since TLB entries incorrectly
tagged with the reserved ASID will never be hit by a later instruction.
Based on work by Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 11 +++++++++++
arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/mmu_context.h | 8 +++++++-
arch/arm64/kernel/cpu_errata.c | 7 +++++++
arch/arm64/mm/context.c | 11 +++++++++++
arch/arm64/mm/proc.S | 1 +
8 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 405da11fc3e4..e090415a97d3 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -63,3 +63,4 @@ stable kernels.
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
| | | | |
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+| Qualcomm | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 111742126897..366c7d4d1cc5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -479,6 +479,17 @@ config CAVIUM_ERRATUM_27456
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_1003
+ bool "Falkor E1003: Incorrect translation due to ASID change"
+ default y
+ help
+ On Falkor v1, an incorrect ASID may be cached in the TLB when ASID
+ and BADDR are changed together in TTBRx_EL1. The workaround for this
+ issue is to use a reserved ASID in cpu_do_switch_mm() before
+ switching to the new ASID.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 3a4301163e04..1b67c3782d00 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -25,6 +25,7 @@
#include <asm/asm-offsets.h>
#include <asm/cpufeature.h>
+#include <asm/mmu_context.h>
#include <asm/page.h>
#include <asm/pgtable-hwdef.h>
#include <asm/ptrace.h>
@@ -441,6 +442,28 @@ alternative_endif
.endm
/*
+ * Errata workaround prior to TTBR0_EL1 update
+ *
+ * val: TTBR value with new BADDR, preserved
+ * tmp0: temporary register, clobbered
+ * tmp1: other temporary register, clobbered
+ */
+ .macro pre_ttbr0_update_workaround, val, tmp0, tmp1
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
+ mrs \tmp0, ttbr0_el1
+ mov \tmp1, #FALKOR_RESERVED_ASID
+ bfi \tmp0, \tmp1, #48, #16 // reserved ASID + old BADDR
+ msr ttbr0_el1, \tmp0
+ isb
+ bfi \tmp0, \val, #0, #48 // reserved ASID + new BADDR
+ msr ttbr0_el1, \tmp0
+ isb
+alternative_else_nop_endif
+#endif
+ .endm
+
+/*
* Errata workaround post TTBR0_EL1 update.
*/
.macro post_ttbr0_update_workaround
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 4174f09678c4..5aaf7eede432 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -35,7 +35,8 @@
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
#define ARM64_HAS_NO_FPSIMD 16
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 17
-#define ARM64_NCAPS 17
+#define ARM64_NCAPS 18
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 0363fe80455c..9632b0508037 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -19,6 +19,10 @@
#ifndef __ASM_MMU_CONTEXT_H
#define __ASM_MMU_CONTEXT_H
+#define FALKOR_RESERVED_ASID 1
+
+#ifndef __ASSEMBLY__
+
#include <linux/compiler.h>
#include <linux/sched.h>
@@ -220,4 +224,6 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
void verify_cpu_asid_bits(void);
-#endif
+#endif /* !__ASSEMBLY__ */
+
+#endif /* !__ASM_MMU_CONTEXT_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index b75e917aac46..787b5422c559 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -130,6 +130,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
.def_scope = SCOPE_LOCAL_CPU,
.enable = cpu_enable_trap_ctr_access,
},
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
+ {
+ .desc = "Qualcomm Falkor erratum 1003",
+ .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1003,
+ MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
+ },
+#endif
{
}
};
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 4c63cb154859..67df38184903 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -79,6 +79,13 @@ void verify_cpu_asid_bits(void)
}
}
+static void set_reserved_asid_bits(void)
+{
+ if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_1003) &&
+ cpus_have_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
+ __set_bit(FALKOR_RESERVED_ASID, asid_map);
+}
+
static void flush_context(unsigned int cpu)
{
int i;
@@ -87,6 +94,8 @@ static void flush_context(unsigned int cpu)
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
+ set_reserved_asid_bits();
+
/*
* Ensure the generation bump is observed before we xchg the
* active_asids.
@@ -244,6 +253,8 @@ static int asids_init(void)
panic("Failed to allocate bitmap for %lu ASIDs\n",
NUM_USER_ASIDS);
+ set_reserved_asid_bits();
+
pr_info("ASID allocator initialised with %lu entries\n", NUM_USER_ASIDS);
return 0;
}
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 32682be978e0..cd4d53d7e458 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -138,6 +138,7 @@ ENDPROC(cpu_do_resume)
* - pgd_phys - physical address of new TTB
*/
ENTRY(cpu_do_switch_mm)
+ pre_ttbr0_update_workaround x0, x1, x2
mmid x1, x1 // get mm->context.id
bfi x0, x1, #48, #16 // set the ASID
msr ttbr0_el1, x0 // set TTBR0
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related [flat|nested] 86+ messages in thread* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-25 15:52 ` Christopher Covington
(?)
@ 2017-01-27 14:38 ` Mark Rutland
-1 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-27 14:38 UTC (permalink / raw)
To: Christopher Covington
Cc: Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
kvm, linux-arm-kernel, kvmarm, linux-kernel, shankerd, timur,
Jonathan Corbet, linux-doc, Jon Masters, Neil Leeder,
Mark Langsdorf
On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
> is triggered, page table entries using the new translation table base
> address (BADDR) will be allocated into the TLB using the old ASID. All
> circumstances leading to the incorrect ASID being cached in the TLB arise
> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
> operation is in the process of performing a translation using the specific
> TTBRx_EL1 being written, and the memory operation uses a translation table
> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
> ASID is not subject to this erratum because hardware is prohibited from
> performing translations from an out-of-context translation regime.
>
> Consider the following pseudo code.
>
> write new BADDR and ASID values to TTBRx_EL1
>
> Replacing the above sequence with the one below will ensure that no TLB
> entries with an incorrect ASID are used by software.
>
> write reserved value to TTBRx_EL1[ASID]
> ISB
> write new value to TTBRx_EL1[BADDR]
> ISB
> write new value to TTBRx_EL1[ASID]
> ISB
>
> When the above sequence is used, page table entries using the new BADDR
> value may still be incorrectly allocated into the TLB using the reserved
> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> tagged with the reserved ASID will never be hit by a later instruction.
I agree that there should be no explicit accesses to the VAs for these
entries. So tasks should not see erroneous VAs, and we shouldn't see
synchronous TLB conflict aborts.
Regardless, can this allow conflicting TLB entries to be allocated to
the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
another has a 2M mapping which covers that VA, can both be allocated
into the TLBs under the reserved ASID?
Can that have any effect on asynchronous TLB lookups or page table
walks, e.g. for speculated accesses?
Thanks,
Mark.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-27 14:38 ` Mark Rutland
0 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-27 14:38 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
> is triggered, page table entries using the new translation table base
> address (BADDR) will be allocated into the TLB using the old ASID. All
> circumstances leading to the incorrect ASID being cached in the TLB arise
> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
> operation is in the process of performing a translation using the specific
> TTBRx_EL1 being written, and the memory operation uses a translation table
> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
> ASID is not subject to this erratum because hardware is prohibited from
> performing translations from an out-of-context translation regime.
>
> Consider the following pseudo code.
>
> write new BADDR and ASID values to TTBRx_EL1
>
> Replacing the above sequence with the one below will ensure that no TLB
> entries with an incorrect ASID are used by software.
>
> write reserved value to TTBRx_EL1[ASID]
> ISB
> write new value to TTBRx_EL1[BADDR]
> ISB
> write new value to TTBRx_EL1[ASID]
> ISB
>
> When the above sequence is used, page table entries using the new BADDR
> value may still be incorrectly allocated into the TLB using the reserved
> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> tagged with the reserved ASID will never be hit by a later instruction.
I agree that there should be no explicit accesses to the VAs for these
entries. So tasks should not see erroneous VAs, and we shouldn't see
synchronous TLB conflict aborts.
Regardless, can this allow conflicting TLB entries to be allocated to
the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
another has a 2M mapping which covers that VA, can both be allocated
into the TLBs under the reserved ASID?
Can that have any effect on asynchronous TLB lookups or page table
walks, e.g. for speculated accesses?
Thanks,
Mark.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-27 14:38 ` Mark Rutland
0 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-27 14:38 UTC (permalink / raw)
To: Christopher Covington
Cc: Mark Langsdorf, linux-doc, kvm, Marc Zyngier, Catalin Marinas,
timur, Jonathan Corbet, Will Deacon, linux-kernel,
linux-arm-kernel, Neil Leeder, Jon Masters, Paolo Bonzini,
kvmarm
On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
> is triggered, page table entries using the new translation table base
> address (BADDR) will be allocated into the TLB using the old ASID. All
> circumstances leading to the incorrect ASID being cached in the TLB arise
> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
> operation is in the process of performing a translation using the specific
> TTBRx_EL1 being written, and the memory operation uses a translation table
> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
> ASID is not subject to this erratum because hardware is prohibited from
> performing translations from an out-of-context translation regime.
>
> Consider the following pseudo code.
>
> write new BADDR and ASID values to TTBRx_EL1
>
> Replacing the above sequence with the one below will ensure that no TLB
> entries with an incorrect ASID are used by software.
>
> write reserved value to TTBRx_EL1[ASID]
> ISB
> write new value to TTBRx_EL1[BADDR]
> ISB
> write new value to TTBRx_EL1[ASID]
> ISB
>
> When the above sequence is used, page table entries using the new BADDR
> value may still be incorrectly allocated into the TLB using the reserved
> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> tagged with the reserved ASID will never be hit by a later instruction.
I agree that there should be no explicit accesses to the VAs for these
entries. So tasks should not see erroneous VAs, and we shouldn't see
synchronous TLB conflict aborts.
Regardless, can this allow conflicting TLB entries to be allocated to
the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
another has a 2M mapping which covers that VA, can both be allocated
into the TLBs under the reserved ASID?
Can that have any effect on asynchronous TLB lookups or page table
walks, e.g. for speculated accesses?
Thanks,
Mark.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-27 14:38 ` Mark Rutland
(?)
@ 2017-01-27 14:43 ` Mark Rutland
-1 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-27 14:43 UTC (permalink / raw)
To: Christopher Covington
Cc: Mark Langsdorf, linux-doc, kvm, Marc Zyngier, Catalin Marinas,
timur, Jonathan Corbet, Will Deacon, linux-kernel,
linux-arm-kernel, Neil Leeder, Jon Masters, Paolo Bonzini,
kvmarm
On Fri, Jan 27, 2017 at 02:38:49PM +0000, Mark Rutland wrote:
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
Urrgh; I used the wrong mail configuration.
Please ignore the above from the prior email.
Mark.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-27 14:43 ` Mark Rutland
0 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-27 14:43 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 27, 2017 at 02:38:49PM +0000, Mark Rutland wrote:
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
Urrgh; I used the wrong mail configuration.
Please ignore the above from the prior email.
Mark.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-27 14:43 ` Mark Rutland
0 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-27 14:43 UTC (permalink / raw)
To: Christopher Covington
Cc: Mark Langsdorf, kvm, linux-doc, Marc Zyngier, Catalin Marinas,
timur, Jonathan Corbet, Will Deacon, linux-kernel, kvmarm,
Jon Masters, Paolo Bonzini, Neil Leeder, linux-arm-kernel
On Fri, Jan 27, 2017 at 02:38:49PM +0000, Mark Rutland wrote:
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
Urrgh; I used the wrong mail configuration.
Please ignore the above from the prior email.
Mark.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-27 14:38 ` Mark Rutland
(?)
@ 2017-01-27 21:52 ` Christopher Covington
-1 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-27 21:52 UTC (permalink / raw)
To: Mark Rutland
Cc: Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
kvm, linux-arm-kernel, kvmarm, linux-kernel, shankerd, timur,
Jonathan Corbet, linux-doc, Jon Masters, Neil Leeder,
Mark Langsdorf
Hi Mark,
On 01/27/2017 09:38 AM, Mark Rutland wrote:
> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>> is triggered, page table entries using the new translation table base
>> address (BADDR) will be allocated into the TLB using the old ASID. All
>> circumstances leading to the incorrect ASID being cached in the TLB arise
>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>> operation is in the process of performing a translation using the specific
>> TTBRx_EL1 being written, and the memory operation uses a translation table
>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>> ASID is not subject to this erratum because hardware is prohibited from
>> performing translations from an out-of-context translation regime.
>>
>> Consider the following pseudo code.
>>
>> write new BADDR and ASID values to TTBRx_EL1
>>
>> Replacing the above sequence with the one below will ensure that no TLB
>> entries with an incorrect ASID are used by software.
>>
>> write reserved value to TTBRx_EL1[ASID]
>> ISB
>> write new value to TTBRx_EL1[BADDR]
>> ISB
>> write new value to TTBRx_EL1[ASID]
>> ISB
>>
>> When the above sequence is used, page table entries using the new BADDR
>> value may still be incorrectly allocated into the TLB using the reserved
>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>> tagged with the reserved ASID will never be hit by a later instruction.
>
> I agree that there should be no explicit accesses to the VAs for these
> entries. So tasks should not see erroneous VAs, and we shouldn't see
> synchronous TLB conflict aborts.
>
> Regardless, can this allow conflicting TLB entries to be allocated to
> the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
> another has a 2M mapping which covers that VA, can both be allocated
> into the TLBs under the reserved ASID?
>
> Can that have any effect on asynchronous TLB lookups or page table
> walks, e.g. for speculated accesses?
A speculative access that inserts an entry into the TLB could
possibly find the conflict but will not signal it. Does that answer
your question?
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-27 21:52 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-27 21:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mark,
On 01/27/2017 09:38 AM, Mark Rutland wrote:
> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>> is triggered, page table entries using the new translation table base
>> address (BADDR) will be allocated into the TLB using the old ASID. All
>> circumstances leading to the incorrect ASID being cached in the TLB arise
>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>> operation is in the process of performing a translation using the specific
>> TTBRx_EL1 being written, and the memory operation uses a translation table
>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>> ASID is not subject to this erratum because hardware is prohibited from
>> performing translations from an out-of-context translation regime.
>>
>> Consider the following pseudo code.
>>
>> write new BADDR and ASID values to TTBRx_EL1
>>
>> Replacing the above sequence with the one below will ensure that no TLB
>> entries with an incorrect ASID are used by software.
>>
>> write reserved value to TTBRx_EL1[ASID]
>> ISB
>> write new value to TTBRx_EL1[BADDR]
>> ISB
>> write new value to TTBRx_EL1[ASID]
>> ISB
>>
>> When the above sequence is used, page table entries using the new BADDR
>> value may still be incorrectly allocated into the TLB using the reserved
>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>> tagged with the reserved ASID will never be hit by a later instruction.
>
> I agree that there should be no explicit accesses to the VAs for these
> entries. So tasks should not see erroneous VAs, and we shouldn't see
> synchronous TLB conflict aborts.
>
> Regardless, can this allow conflicting TLB entries to be allocated to
> the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
> another has a 2M mapping which covers that VA, can both be allocated
> into the TLBs under the reserved ASID?
>
> Can that have any effect on asynchronous TLB lookups or page table
> walks, e.g. for speculated accesses?
A speculative access that inserts an entry into the TLB could
possibly find the conflict but will not signal it. Does that answer
your question?
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-27 21:52 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-27 21:52 UTC (permalink / raw)
To: Mark Rutland
Cc: Mark Langsdorf, linux-doc, kvm, Marc Zyngier, Catalin Marinas,
timur, Jonathan Corbet, Will Deacon, linux-kernel,
linux-arm-kernel, Neil Leeder, Jon Masters, Paolo Bonzini,
kvmarm
Hi Mark,
On 01/27/2017 09:38 AM, Mark Rutland wrote:
> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>> is triggered, page table entries using the new translation table base
>> address (BADDR) will be allocated into the TLB using the old ASID. All
>> circumstances leading to the incorrect ASID being cached in the TLB arise
>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>> operation is in the process of performing a translation using the specific
>> TTBRx_EL1 being written, and the memory operation uses a translation table
>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>> ASID is not subject to this erratum because hardware is prohibited from
>> performing translations from an out-of-context translation regime.
>>
>> Consider the following pseudo code.
>>
>> write new BADDR and ASID values to TTBRx_EL1
>>
>> Replacing the above sequence with the one below will ensure that no TLB
>> entries with an incorrect ASID are used by software.
>>
>> write reserved value to TTBRx_EL1[ASID]
>> ISB
>> write new value to TTBRx_EL1[BADDR]
>> ISB
>> write new value to TTBRx_EL1[ASID]
>> ISB
>>
>> When the above sequence is used, page table entries using the new BADDR
>> value may still be incorrectly allocated into the TLB using the reserved
>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>> tagged with the reserved ASID will never be hit by a later instruction.
>
> I agree that there should be no explicit accesses to the VAs for these
> entries. So tasks should not see erroneous VAs, and we shouldn't see
> synchronous TLB conflict aborts.
>
> Regardless, can this allow conflicting TLB entries to be allocated to
> the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
> another has a 2M mapping which covers that VA, can both be allocated
> into the TLBs under the reserved ASID?
>
> Can that have any effect on asynchronous TLB lookups or page table
> walks, e.g. for speculated accesses?
A speculative access that inserts an entry into the TLB could
possibly find the conflict but will not signal it. Does that answer
your question?
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-27 21:52 ` Christopher Covington
(?)
@ 2017-01-30 10:56 ` Mark Rutland
-1 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-30 10:56 UTC (permalink / raw)
To: Christopher Covington
Cc: Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
kvm, linux-arm-kernel, kvmarm, linux-kernel, shankerd, timur,
Jonathan Corbet, linux-doc, Jon Masters, Neil Leeder,
Mark Langsdorf
Hi,
On Fri, Jan 27, 2017 at 04:52:23PM -0500, Christopher Covington wrote:
> On 01/27/2017 09:38 AM, Mark Rutland wrote:
> > On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> >> Replacing the above sequence with the one below will ensure that no TLB
> >> entries with an incorrect ASID are used by software.
> >>
> >> write reserved value to TTBRx_EL1[ASID]
> >> ISB
> >> write new value to TTBRx_EL1[BADDR]
> >> ISB
> >> write new value to TTBRx_EL1[ASID]
> >> ISB
> >>
> >> When the above sequence is used, page table entries using the new BADDR
> >> value may still be incorrectly allocated into the TLB using the reserved
> >> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> >> tagged with the reserved ASID will never be hit by a later instruction.
> >
> > I agree that there should be no explicit accesses to the VAs for these
> > entries. So tasks should not see erroneous VAs, and we shouldn't see
> > synchronous TLB conflict aborts.
> >
> > Regardless, can this allow conflicting TLB entries to be allocated to
> > the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
> > another has a 2M mapping which covers that VA, can both be allocated
> > into the TLBs under the reserved ASID?
> >
> > Can that have any effect on asynchronous TLB lookups or page table
> > walks, e.g. for speculated accesses?
>
> A speculative access that inserts an entry into the TLB could
> possibly find the conflict but will not signal it. Does that answer
> your question?
Yes!
The other case I was worried about was intermediate caching. I take it
the values in TLBs are not used as part of subsequent page table walks?
If so, the above sounds fine to me.
Otherwise, we'll need additional TLB maintenance.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-30 10:56 ` Mark Rutland
0 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-30 10:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, Jan 27, 2017 at 04:52:23PM -0500, Christopher Covington wrote:
> On 01/27/2017 09:38 AM, Mark Rutland wrote:
> > On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> >> Replacing the above sequence with the one below will ensure that no TLB
> >> entries with an incorrect ASID are used by software.
> >>
> >> write reserved value to TTBRx_EL1[ASID]
> >> ISB
> >> write new value to TTBRx_EL1[BADDR]
> >> ISB
> >> write new value to TTBRx_EL1[ASID]
> >> ISB
> >>
> >> When the above sequence is used, page table entries using the new BADDR
> >> value may still be incorrectly allocated into the TLB using the reserved
> >> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> >> tagged with the reserved ASID will never be hit by a later instruction.
> >
> > I agree that there should be no explicit accesses to the VAs for these
> > entries. So tasks should not see erroneous VAs, and we shouldn't see
> > synchronous TLB conflict aborts.
> >
> > Regardless, can this allow conflicting TLB entries to be allocated to
> > the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
> > another has a 2M mapping which covers that VA, can both be allocated
> > into the TLBs under the reserved ASID?
> >
> > Can that have any effect on asynchronous TLB lookups or page table
> > walks, e.g. for speculated accesses?
>
> A speculative access that inserts an entry into the TLB could
> possibly find the conflict but will not signal it. Does that answer
> your question?
Yes!
The other case I was worried about was intermediate caching. I take it
the values in TLBs are not used as part of subsequent page table walks?
If so, the above sounds fine to me.
Otherwise, we'll need additional TLB maintenance.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-30 10:56 ` Mark Rutland
0 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-30 10:56 UTC (permalink / raw)
To: Christopher Covington
Cc: Mark Langsdorf, linux-doc, kvm, Marc Zyngier, Catalin Marinas,
timur, Jonathan Corbet, Will Deacon, linux-kernel,
linux-arm-kernel, Neil Leeder, Jon Masters, Paolo Bonzini,
kvmarm
Hi,
On Fri, Jan 27, 2017 at 04:52:23PM -0500, Christopher Covington wrote:
> On 01/27/2017 09:38 AM, Mark Rutland wrote:
> > On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> >> Replacing the above sequence with the one below will ensure that no TLB
> >> entries with an incorrect ASID are used by software.
> >>
> >> write reserved value to TTBRx_EL1[ASID]
> >> ISB
> >> write new value to TTBRx_EL1[BADDR]
> >> ISB
> >> write new value to TTBRx_EL1[ASID]
> >> ISB
> >>
> >> When the above sequence is used, page table entries using the new BADDR
> >> value may still be incorrectly allocated into the TLB using the reserved
> >> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> >> tagged with the reserved ASID will never be hit by a later instruction.
> >
> > I agree that there should be no explicit accesses to the VAs for these
> > entries. So tasks should not see erroneous VAs, and we shouldn't see
> > synchronous TLB conflict aborts.
> >
> > Regardless, can this allow conflicting TLB entries to be allocated to
> > the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
> > another has a 2M mapping which covers that VA, can both be allocated
> > into the TLBs under the reserved ASID?
> >
> > Can that have any effect on asynchronous TLB lookups or page table
> > walks, e.g. for speculated accesses?
>
> A speculative access that inserts an entry into the TLB could
> possibly find the conflict but will not signal it. Does that answer
> your question?
Yes!
The other case I was worried about was intermediate caching. I take it
the values in TLBs are not used as part of subsequent page table walks?
If so, the above sounds fine to me.
Otherwise, we'll need additional TLB maintenance.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-30 10:56 ` Mark Rutland
(?)
@ 2017-01-30 22:09 ` Christopher Covington
-1 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-30 22:09 UTC (permalink / raw)
To: Mark Rutland
Cc: Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
kvm, linux-arm-kernel, kvmarm, linux-kernel, shankerd, timur,
Jonathan Corbet, linux-doc, Jon Masters, Neil Leeder,
Mark Langsdorf
Hi Mark,
On 01/30/2017 05:56 AM, Mark Rutland wrote:
> Hi,
>
> On Fri, Jan 27, 2017 at 04:52:23PM -0500, Christopher Covington wrote:
>> On 01/27/2017 09:38 AM, Mark Rutland wrote:
>>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>
>>>> Replacing the above sequence with the one below will ensure that no TLB
>>>> entries with an incorrect ASID are used by software.
>>>>
>>>> write reserved value to TTBRx_EL1[ASID]
>>>> ISB
>>>> write new value to TTBRx_EL1[BADDR]
>>>> ISB
>>>> write new value to TTBRx_EL1[ASID]
>>>> ISB
>>>>
>>>> When the above sequence is used, page table entries using the new BADDR
>>>> value may still be incorrectly allocated into the TLB using the reserved
>>>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>>>> tagged with the reserved ASID will never be hit by a later instruction.
>>>
>>> I agree that there should be no explicit accesses to the VAs for these
>>> entries. So tasks should not see erroneous VAs, and we shouldn't see
>>> synchronous TLB conflict aborts.
>>>
>>> Regardless, can this allow conflicting TLB entries to be allocated to
>>> the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
>>> another has a 2M mapping which covers that VA, can both be allocated
>>> into the TLBs under the reserved ASID?
>>>
>>> Can that have any effect on asynchronous TLB lookups or page table
>>> walks, e.g. for speculated accesses?
>>
>> A speculative access that inserts an entry into the TLB could
>> possibly find the conflict but will not signal it. Does that answer
>> your question?
>
> Yes!
>
> The other case I was worried about was intermediate caching. I take it
> the values in TLBs are not used as part of subsequent page table walks?
>
> If so, the above sounds fine to me.
>
> Otherwise, we'll need additional TLB maintenance.
Errant TLB entries will not be used for any legitimate subsequent page
table walks.
I have some minor changes which I'll send as v5 based on
kernel/git/arm64/linux.git for-next/core.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-30 22:09 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-30 22:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mark,
On 01/30/2017 05:56 AM, Mark Rutland wrote:
> Hi,
>
> On Fri, Jan 27, 2017 at 04:52:23PM -0500, Christopher Covington wrote:
>> On 01/27/2017 09:38 AM, Mark Rutland wrote:
>>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>
>>>> Replacing the above sequence with the one below will ensure that no TLB
>>>> entries with an incorrect ASID are used by software.
>>>>
>>>> write reserved value to TTBRx_EL1[ASID]
>>>> ISB
>>>> write new value to TTBRx_EL1[BADDR]
>>>> ISB
>>>> write new value to TTBRx_EL1[ASID]
>>>> ISB
>>>>
>>>> When the above sequence is used, page table entries using the new BADDR
>>>> value may still be incorrectly allocated into the TLB using the reserved
>>>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>>>> tagged with the reserved ASID will never be hit by a later instruction.
>>>
>>> I agree that there should be no explicit accesses to the VAs for these
>>> entries. So tasks should not see erroneous VAs, and we shouldn't see
>>> synchronous TLB conflict aborts.
>>>
>>> Regardless, can this allow conflicting TLB entries to be allocated to
>>> the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
>>> another has a 2M mapping which covers that VA, can both be allocated
>>> into the TLBs under the reserved ASID?
>>>
>>> Can that have any effect on asynchronous TLB lookups or page table
>>> walks, e.g. for speculated accesses?
>>
>> A speculative access that inserts an entry into the TLB could
>> possibly find the conflict but will not signal it. Does that answer
>> your question?
>
> Yes!
>
> The other case I was worried about was intermediate caching. I take it
> the values in TLBs are not used as part of subsequent page table walks?
>
> If so, the above sounds fine to me.
>
> Otherwise, we'll need additional TLB maintenance.
Errant TLB entries will not be used for any legitimate subsequent page
table walks.
I have some minor changes which I'll send as v5 based on
kernel/git/arm64/linux.git for-next/core.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-30 22:09 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-30 22:09 UTC (permalink / raw)
To: Mark Rutland
Cc: Mark Langsdorf, linux-doc, kvm, Marc Zyngier, Catalin Marinas,
timur, Jonathan Corbet, Will Deacon, linux-kernel,
linux-arm-kernel, Neil Leeder, Jon Masters, Paolo Bonzini,
kvmarm
Hi Mark,
On 01/30/2017 05:56 AM, Mark Rutland wrote:
> Hi,
>
> On Fri, Jan 27, 2017 at 04:52:23PM -0500, Christopher Covington wrote:
>> On 01/27/2017 09:38 AM, Mark Rutland wrote:
>>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>
>>>> Replacing the above sequence with the one below will ensure that no TLB
>>>> entries with an incorrect ASID are used by software.
>>>>
>>>> write reserved value to TTBRx_EL1[ASID]
>>>> ISB
>>>> write new value to TTBRx_EL1[BADDR]
>>>> ISB
>>>> write new value to TTBRx_EL1[ASID]
>>>> ISB
>>>>
>>>> When the above sequence is used, page table entries using the new BADDR
>>>> value may still be incorrectly allocated into the TLB using the reserved
>>>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>>>> tagged with the reserved ASID will never be hit by a later instruction.
>>>
>>> I agree that there should be no explicit accesses to the VAs for these
>>> entries. So tasks should not see erroneous VAs, and we shouldn't see
>>> synchronous TLB conflict aborts.
>>>
>>> Regardless, can this allow conflicting TLB entries to be allocated to
>>> the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
>>> another has a 2M mapping which covers that VA, can both be allocated
>>> into the TLBs under the reserved ASID?
>>>
>>> Can that have any effect on asynchronous TLB lookups or page table
>>> walks, e.g. for speculated accesses?
>>
>> A speculative access that inserts an entry into the TLB could
>> possibly find the conflict but will not signal it. Does that answer
>> your question?
>
> Yes!
>
> The other case I was worried about was intermediate caching. I take it
> the values in TLBs are not used as part of subsequent page table walks?
>
> If so, the above sounds fine to me.
>
> Otherwise, we'll need additional TLB maintenance.
Errant TLB entries will not be used for any legitimate subsequent page
table walks.
I have some minor changes which I'll send as v5 based on
kernel/git/arm64/linux.git for-next/core.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-25 15:52 ` Christopher Covington
(?)
@ 2017-01-27 19:18 ` Timur Tabi
-1 siblings, 0 replies; 86+ messages in thread
From: Timur Tabi @ 2017-01-27 19:18 UTC (permalink / raw)
To: Christopher Covington, Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
kvm, linux-arm-kernel, kvmarm, linux-kernel, shankerd,
Jonathan Corbet, linux-doc
Cc: Mark Langsdorf, Mark Salter, Jon Masters, Neil Leeder
On 01/25/2017 09:52 AM, Christopher Covington wrote:
> + .desc = "Qualcomm Falkor erratum 1003",
FYI, this needs to say, "Qualcomm Technologies Falkor ...". Same thing with
the 1009 patch.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-27 19:18 ` Timur Tabi
0 siblings, 0 replies; 86+ messages in thread
From: Timur Tabi @ 2017-01-27 19:18 UTC (permalink / raw)
To: linux-arm-kernel
On 01/25/2017 09:52 AM, Christopher Covington wrote:
> + .desc = "Qualcomm Falkor erratum 1003",
FYI, this needs to say, "Qualcomm Technologies Falkor ...". Same thing with
the 1009 patch.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-27 19:18 ` Timur Tabi
0 siblings, 0 replies; 86+ messages in thread
From: Timur Tabi @ 2017-01-27 19:18 UTC (permalink / raw)
To: Christopher Covington, Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
kvm, linux-arm-kernel, kvmarm, linux-kernel, shankerd,
Jonathan Corbet, linux-doc
Cc: Jon Masters, Neil Leeder, Mark Langsdorf, Mark Salter
On 01/25/2017 09:52 AM, Christopher Covington wrote:
> + .desc = "Qualcomm Falkor erratum 1003",
FYI, this needs to say, "Qualcomm Technologies Falkor ...". Same thing with
the 1009 patch.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-25 15:52 ` Christopher Covington
(?)
@ 2017-01-31 12:37 ` Mark Rutland
-1 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-31 12:37 UTC (permalink / raw)
To: Christopher Covington
Cc: Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
kvm, linux-arm-kernel, kvmarm, linux-kernel, shankerd, timur,
Jonathan Corbet, linux-doc, Jon Masters, Neil Leeder,
Mark Langsdorf
On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
> is triggered, page table entries using the new translation table base
> address (BADDR) will be allocated into the TLB using the old ASID. All
> circumstances leading to the incorrect ASID being cached in the TLB arise
> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
> operation is in the process of performing a translation using the specific
> TTBRx_EL1 being written, and the memory operation uses a translation table
> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
> ASID is not subject to this erratum because hardware is prohibited from
> performing translations from an out-of-context translation regime.
>
> Consider the following pseudo code.
>
> write new BADDR and ASID values to TTBRx_EL1
>
> Replacing the above sequence with the one below will ensure that no TLB
> entries with an incorrect ASID are used by software.
>
> write reserved value to TTBRx_EL1[ASID]
> ISB
> write new value to TTBRx_EL1[BADDR]
> ISB
> write new value to TTBRx_EL1[ASID]
> ISB
>
> When the above sequence is used, page table entries using the new BADDR
> value may still be incorrectly allocated into the TLB using the reserved
> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> tagged with the reserved ASID will never be hit by a later instruction.
Based on my understanding that entries allocated to the reserved ASID
will not be used for subsequent page table walks (and so we don't have
asynchronous behaviour to contend with), this sounds fine to me.
Thanks for taking the time to clarify the details on that.
> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 11 +++++++++++
> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
> arch/arm64/include/asm/cpucaps.h | 3 ++-
> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
> arch/arm64/kernel/cpu_errata.c | 7 +++++++
> arch/arm64/mm/context.c | 11 +++++++++++
> arch/arm64/mm/proc.S | 1 +
> 8 files changed, 63 insertions(+), 2 deletions(-)
Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
for the empty table in __uaccess_ttbr0_disable.
That also means we have to invalidate the reserved ASID so as to not
accidentally hit while uaccess is disabled.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-31 12:37 ` Mark Rutland
0 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-31 12:37 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
> is triggered, page table entries using the new translation table base
> address (BADDR) will be allocated into the TLB using the old ASID. All
> circumstances leading to the incorrect ASID being cached in the TLB arise
> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
> operation is in the process of performing a translation using the specific
> TTBRx_EL1 being written, and the memory operation uses a translation table
> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
> ASID is not subject to this erratum because hardware is prohibited from
> performing translations from an out-of-context translation regime.
>
> Consider the following pseudo code.
>
> write new BADDR and ASID values to TTBRx_EL1
>
> Replacing the above sequence with the one below will ensure that no TLB
> entries with an incorrect ASID are used by software.
>
> write reserved value to TTBRx_EL1[ASID]
> ISB
> write new value to TTBRx_EL1[BADDR]
> ISB
> write new value to TTBRx_EL1[ASID]
> ISB
>
> When the above sequence is used, page table entries using the new BADDR
> value may still be incorrectly allocated into the TLB using the reserved
> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> tagged with the reserved ASID will never be hit by a later instruction.
Based on my understanding that entries allocated to the reserved ASID
will not be used for subsequent page table walks (and so we don't have
asynchronous behaviour to contend with), this sounds fine to me.
Thanks for taking the time to clarify the details on that.
> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 11 +++++++++++
> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
> arch/arm64/include/asm/cpucaps.h | 3 ++-
> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
> arch/arm64/kernel/cpu_errata.c | 7 +++++++
> arch/arm64/mm/context.c | 11 +++++++++++
> arch/arm64/mm/proc.S | 1 +
> 8 files changed, 63 insertions(+), 2 deletions(-)
Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
for the empty table in __uaccess_ttbr0_disable.
That also means we have to invalidate the reserved ASID so as to not
accidentally hit while uaccess is disabled.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-31 12:37 ` Mark Rutland
0 siblings, 0 replies; 86+ messages in thread
From: Mark Rutland @ 2017-01-31 12:37 UTC (permalink / raw)
To: Christopher Covington
Cc: Mark Langsdorf, linux-doc, kvm, Marc Zyngier, Catalin Marinas,
timur, Jonathan Corbet, Will Deacon, linux-kernel,
linux-arm-kernel, Neil Leeder, Jon Masters, Paolo Bonzini,
kvmarm
On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
> is triggered, page table entries using the new translation table base
> address (BADDR) will be allocated into the TLB using the old ASID. All
> circumstances leading to the incorrect ASID being cached in the TLB arise
> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
> operation is in the process of performing a translation using the specific
> TTBRx_EL1 being written, and the memory operation uses a translation table
> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
> ASID is not subject to this erratum because hardware is prohibited from
> performing translations from an out-of-context translation regime.
>
> Consider the following pseudo code.
>
> write new BADDR and ASID values to TTBRx_EL1
>
> Replacing the above sequence with the one below will ensure that no TLB
> entries with an incorrect ASID are used by software.
>
> write reserved value to TTBRx_EL1[ASID]
> ISB
> write new value to TTBRx_EL1[BADDR]
> ISB
> write new value to TTBRx_EL1[ASID]
> ISB
>
> When the above sequence is used, page table entries using the new BADDR
> value may still be incorrectly allocated into the TLB using the reserved
> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> tagged with the reserved ASID will never be hit by a later instruction.
Based on my understanding that entries allocated to the reserved ASID
will not be used for subsequent page table walks (and so we don't have
asynchronous behaviour to contend with), this sounds fine to me.
Thanks for taking the time to clarify the details on that.
> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 11 +++++++++++
> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
> arch/arm64/include/asm/cpucaps.h | 3 ++-
> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
> arch/arm64/kernel/cpu_errata.c | 7 +++++++
> arch/arm64/mm/context.c | 11 +++++++++++
> arch/arm64/mm/proc.S | 1 +
> 8 files changed, 63 insertions(+), 2 deletions(-)
Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
for the empty table in __uaccess_ttbr0_disable.
That also means we have to invalidate the reserved ASID so as to not
accidentally hit while uaccess is disabled.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-31 12:37 ` Mark Rutland
(?)
@ 2017-01-31 17:48 ` Christopher Covington
-1 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-31 17:48 UTC (permalink / raw)
To: Mark Rutland
Cc: Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
kvm, linux-arm-kernel, kvmarm, linux-kernel, shankerd, timur,
Jonathan Corbet, linux-doc, Jon Masters, Neil Leeder,
Mark Langsdorf
On 01/31/2017 07:37 AM, Mark Rutland wrote:
> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>> is triggered, page table entries using the new translation table base
>> address (BADDR) will be allocated into the TLB using the old ASID. All
>> circumstances leading to the incorrect ASID being cached in the TLB arise
>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>> operation is in the process of performing a translation using the specific
>> TTBRx_EL1 being written, and the memory operation uses a translation table
>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>> ASID is not subject to this erratum because hardware is prohibited from
>> performing translations from an out-of-context translation regime.
>>
>> Consider the following pseudo code.
>>
>> write new BADDR and ASID values to TTBRx_EL1
>>
>> Replacing the above sequence with the one below will ensure that no TLB
>> entries with an incorrect ASID are used by software.
>>
>> write reserved value to TTBRx_EL1[ASID]
>> ISB
>> write new value to TTBRx_EL1[BADDR]
>> ISB
>> write new value to TTBRx_EL1[ASID]
>> ISB
>>
>> When the above sequence is used, page table entries using the new BADDR
>> value may still be incorrectly allocated into the TLB using the reserved
>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>> tagged with the reserved ASID will never be hit by a later instruction.
>
> Based on my understanding that entries allocated to the reserved ASID
> will not be used for subsequent page table walks (and so we don't have
> asynchronous behaviour to contend with), this sounds fine to me.
>
> Thanks for taking the time to clarify the details on that.
>
>> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>>
>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>> ---
>> Documentation/arm64/silicon-errata.txt | 1 +
>> arch/arm64/Kconfig | 11 +++++++++++
>> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
>> arch/arm64/kernel/cpu_errata.c | 7 +++++++
>> arch/arm64/mm/context.c | 11 +++++++++++
>> arch/arm64/mm/proc.S | 1 +
>> 8 files changed, 63 insertions(+), 2 deletions(-)
>
> Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
> for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
> for the empty table in __uaccess_ttbr0_disable.
>
> That also means we have to invalidate the reserved ASID so as to not
> accidentally hit while uaccess is disabled.
The CPU in question (Falkor v1) has hardware PAN support. Do we need
to worry about including the workaround in the SW PAN code in that case?
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-31 17:48 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-31 17:48 UTC (permalink / raw)
To: linux-arm-kernel
On 01/31/2017 07:37 AM, Mark Rutland wrote:
> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>> is triggered, page table entries using the new translation table base
>> address (BADDR) will be allocated into the TLB using the old ASID. All
>> circumstances leading to the incorrect ASID being cached in the TLB arise
>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>> operation is in the process of performing a translation using the specific
>> TTBRx_EL1 being written, and the memory operation uses a translation table
>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>> ASID is not subject to this erratum because hardware is prohibited from
>> performing translations from an out-of-context translation regime.
>>
>> Consider the following pseudo code.
>>
>> write new BADDR and ASID values to TTBRx_EL1
>>
>> Replacing the above sequence with the one below will ensure that no TLB
>> entries with an incorrect ASID are used by software.
>>
>> write reserved value to TTBRx_EL1[ASID]
>> ISB
>> write new value to TTBRx_EL1[BADDR]
>> ISB
>> write new value to TTBRx_EL1[ASID]
>> ISB
>>
>> When the above sequence is used, page table entries using the new BADDR
>> value may still be incorrectly allocated into the TLB using the reserved
>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>> tagged with the reserved ASID will never be hit by a later instruction.
>
> Based on my understanding that entries allocated to the reserved ASID
> will not be used for subsequent page table walks (and so we don't have
> asynchronous behaviour to contend with), this sounds fine to me.
>
> Thanks for taking the time to clarify the details on that.
>
>> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>>
>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>> ---
>> Documentation/arm64/silicon-errata.txt | 1 +
>> arch/arm64/Kconfig | 11 +++++++++++
>> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
>> arch/arm64/kernel/cpu_errata.c | 7 +++++++
>> arch/arm64/mm/context.c | 11 +++++++++++
>> arch/arm64/mm/proc.S | 1 +
>> 8 files changed, 63 insertions(+), 2 deletions(-)
>
> Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
> for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
> for the empty table in __uaccess_ttbr0_disable.
>
> That also means we have to invalidate the reserved ASID so as to not
> accidentally hit while uaccess is disabled.
The CPU in question (Falkor v1) has hardware PAN support. Do we need
to worry about including the workaround in the SW PAN code in that case?
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-31 17:48 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-01-31 17:48 UTC (permalink / raw)
To: Mark Rutland
Cc: Mark Langsdorf, linux-doc, kvm, Marc Zyngier, Catalin Marinas,
timur, Jonathan Corbet, Will Deacon, linux-kernel,
linux-arm-kernel, Neil Leeder, Jon Masters, Paolo Bonzini,
kvmarm
On 01/31/2017 07:37 AM, Mark Rutland wrote:
> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>> is triggered, page table entries using the new translation table base
>> address (BADDR) will be allocated into the TLB using the old ASID. All
>> circumstances leading to the incorrect ASID being cached in the TLB arise
>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>> operation is in the process of performing a translation using the specific
>> TTBRx_EL1 being written, and the memory operation uses a translation table
>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>> ASID is not subject to this erratum because hardware is prohibited from
>> performing translations from an out-of-context translation regime.
>>
>> Consider the following pseudo code.
>>
>> write new BADDR and ASID values to TTBRx_EL1
>>
>> Replacing the above sequence with the one below will ensure that no TLB
>> entries with an incorrect ASID are used by software.
>>
>> write reserved value to TTBRx_EL1[ASID]
>> ISB
>> write new value to TTBRx_EL1[BADDR]
>> ISB
>> write new value to TTBRx_EL1[ASID]
>> ISB
>>
>> When the above sequence is used, page table entries using the new BADDR
>> value may still be incorrectly allocated into the TLB using the reserved
>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>> tagged with the reserved ASID will never be hit by a later instruction.
>
> Based on my understanding that entries allocated to the reserved ASID
> will not be used for subsequent page table walks (and so we don't have
> asynchronous behaviour to contend with), this sounds fine to me.
>
> Thanks for taking the time to clarify the details on that.
>
>> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>>
>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>> ---
>> Documentation/arm64/silicon-errata.txt | 1 +
>> arch/arm64/Kconfig | 11 +++++++++++
>> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
>> arch/arm64/kernel/cpu_errata.c | 7 +++++++
>> arch/arm64/mm/context.c | 11 +++++++++++
>> arch/arm64/mm/proc.S | 1 +
>> 8 files changed, 63 insertions(+), 2 deletions(-)
>
> Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
> for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
> for the empty table in __uaccess_ttbr0_disable.
>
> That also means we have to invalidate the reserved ASID so as to not
> accidentally hit while uaccess is disabled.
The CPU in question (Falkor v1) has hardware PAN support. Do we need
to worry about including the workaround in the SW PAN code in that case?
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-31 17:48 ` Christopher Covington
(?)
@ 2017-01-31 17:56 ` Marc Zyngier
-1 siblings, 0 replies; 86+ messages in thread
From: Marc Zyngier @ 2017-01-31 17:56 UTC (permalink / raw)
To: Christopher Covington, Mark Rutland
Cc: Paolo Bonzini, Radim Krčmář,
Christoffer Dall, Catalin Marinas, Will Deacon, kvm,
linux-arm-kernel, kvmarm, linux-kernel, shankerd, timur,
Jonathan Corbet, linux-doc, Jon Masters, Neil Leeder,
Mark Langsdorf
On 31/01/17 17:48, Christopher Covington wrote:
> On 01/31/2017 07:37 AM, Mark Rutland wrote:
>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>>> is triggered, page table entries using the new translation table base
>>> address (BADDR) will be allocated into the TLB using the old ASID. All
>>> circumstances leading to the incorrect ASID being cached in the TLB arise
>>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>>> operation is in the process of performing a translation using the specific
>>> TTBRx_EL1 being written, and the memory operation uses a translation table
>>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>>> ASID is not subject to this erratum because hardware is prohibited from
>>> performing translations from an out-of-context translation regime.
>>>
>>> Consider the following pseudo code.
>>>
>>> write new BADDR and ASID values to TTBRx_EL1
>>>
>>> Replacing the above sequence with the one below will ensure that no TLB
>>> entries with an incorrect ASID are used by software.
>>>
>>> write reserved value to TTBRx_EL1[ASID]
>>> ISB
>>> write new value to TTBRx_EL1[BADDR]
>>> ISB
>>> write new value to TTBRx_EL1[ASID]
>>> ISB
>>>
>>> When the above sequence is used, page table entries using the new BADDR
>>> value may still be incorrectly allocated into the TLB using the reserved
>>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>>> tagged with the reserved ASID will never be hit by a later instruction.
>>
>> Based on my understanding that entries allocated to the reserved ASID
>> will not be used for subsequent page table walks (and so we don't have
>> asynchronous behaviour to contend with), this sounds fine to me.
>>
>> Thanks for taking the time to clarify the details on that.
>>
>>> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>>>
>>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>>> ---
>>> Documentation/arm64/silicon-errata.txt | 1 +
>>> arch/arm64/Kconfig | 11 +++++++++++
>>> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
>>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>>> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
>>> arch/arm64/kernel/cpu_errata.c | 7 +++++++
>>> arch/arm64/mm/context.c | 11 +++++++++++
>>> arch/arm64/mm/proc.S | 1 +
>>> 8 files changed, 63 insertions(+), 2 deletions(-)
>>
>> Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
>> for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
>> for the empty table in __uaccess_ttbr0_disable.
>>
>> That also means we have to invalidate the reserved ASID so as to not
>> accidentally hit while uaccess is disabled.
>
> The CPU in question (Falkor v1) has hardware PAN support. Do we need
> to worry about including the workaround in the SW PAN code in that case?
Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
that case too, and hope that people do enable the HW version.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-31 17:56 ` Marc Zyngier
0 siblings, 0 replies; 86+ messages in thread
From: Marc Zyngier @ 2017-01-31 17:56 UTC (permalink / raw)
To: linux-arm-kernel
On 31/01/17 17:48, Christopher Covington wrote:
> On 01/31/2017 07:37 AM, Mark Rutland wrote:
>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>>> is triggered, page table entries using the new translation table base
>>> address (BADDR) will be allocated into the TLB using the old ASID. All
>>> circumstances leading to the incorrect ASID being cached in the TLB arise
>>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>>> operation is in the process of performing a translation using the specific
>>> TTBRx_EL1 being written, and the memory operation uses a translation table
>>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>>> ASID is not subject to this erratum because hardware is prohibited from
>>> performing translations from an out-of-context translation regime.
>>>
>>> Consider the following pseudo code.
>>>
>>> write new BADDR and ASID values to TTBRx_EL1
>>>
>>> Replacing the above sequence with the one below will ensure that no TLB
>>> entries with an incorrect ASID are used by software.
>>>
>>> write reserved value to TTBRx_EL1[ASID]
>>> ISB
>>> write new value to TTBRx_EL1[BADDR]
>>> ISB
>>> write new value to TTBRx_EL1[ASID]
>>> ISB
>>>
>>> When the above sequence is used, page table entries using the new BADDR
>>> value may still be incorrectly allocated into the TLB using the reserved
>>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>>> tagged with the reserved ASID will never be hit by a later instruction.
>>
>> Based on my understanding that entries allocated to the reserved ASID
>> will not be used for subsequent page table walks (and so we don't have
>> asynchronous behaviour to contend with), this sounds fine to me.
>>
>> Thanks for taking the time to clarify the details on that.
>>
>>> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>>>
>>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>>> ---
>>> Documentation/arm64/silicon-errata.txt | 1 +
>>> arch/arm64/Kconfig | 11 +++++++++++
>>> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
>>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>>> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
>>> arch/arm64/kernel/cpu_errata.c | 7 +++++++
>>> arch/arm64/mm/context.c | 11 +++++++++++
>>> arch/arm64/mm/proc.S | 1 +
>>> 8 files changed, 63 insertions(+), 2 deletions(-)
>>
>> Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
>> for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
>> for the empty table in __uaccess_ttbr0_disable.
>>
>> That also means we have to invalidate the reserved ASID so as to not
>> accidentally hit while uaccess is disabled.
>
> The CPU in question (Falkor v1) has hardware PAN support. Do we need
> to worry about including the workaround in the SW PAN code in that case?
Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
that case too, and hope that people do enable the HW version.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-01-31 17:56 ` Marc Zyngier
0 siblings, 0 replies; 86+ messages in thread
From: Marc Zyngier @ 2017-01-31 17:56 UTC (permalink / raw)
To: Christopher Covington, Mark Rutland
Cc: Mark Langsdorf, linux-doc, kvm, Catalin Marinas, timur,
Jonathan Corbet, Will Deacon, linux-kernel, linux-arm-kernel,
Neil Leeder, Jon Masters, Paolo Bonzini, kvmarm
On 31/01/17 17:48, Christopher Covington wrote:
> On 01/31/2017 07:37 AM, Mark Rutland wrote:
>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>>> is triggered, page table entries using the new translation table base
>>> address (BADDR) will be allocated into the TLB using the old ASID. All
>>> circumstances leading to the incorrect ASID being cached in the TLB arise
>>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>>> operation is in the process of performing a translation using the specific
>>> TTBRx_EL1 being written, and the memory operation uses a translation table
>>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>>> ASID is not subject to this erratum because hardware is prohibited from
>>> performing translations from an out-of-context translation regime.
>>>
>>> Consider the following pseudo code.
>>>
>>> write new BADDR and ASID values to TTBRx_EL1
>>>
>>> Replacing the above sequence with the one below will ensure that no TLB
>>> entries with an incorrect ASID are used by software.
>>>
>>> write reserved value to TTBRx_EL1[ASID]
>>> ISB
>>> write new value to TTBRx_EL1[BADDR]
>>> ISB
>>> write new value to TTBRx_EL1[ASID]
>>> ISB
>>>
>>> When the above sequence is used, page table entries using the new BADDR
>>> value may still be incorrectly allocated into the TLB using the reserved
>>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>>> tagged with the reserved ASID will never be hit by a later instruction.
>>
>> Based on my understanding that entries allocated to the reserved ASID
>> will not be used for subsequent page table walks (and so we don't have
>> asynchronous behaviour to contend with), this sounds fine to me.
>>
>> Thanks for taking the time to clarify the details on that.
>>
>>> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>>>
>>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>>> ---
>>> Documentation/arm64/silicon-errata.txt | 1 +
>>> arch/arm64/Kconfig | 11 +++++++++++
>>> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
>>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>>> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
>>> arch/arm64/kernel/cpu_errata.c | 7 +++++++
>>> arch/arm64/mm/context.c | 11 +++++++++++
>>> arch/arm64/mm/proc.S | 1 +
>>> 8 files changed, 63 insertions(+), 2 deletions(-)
>>
>> Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
>> for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
>> for the empty table in __uaccess_ttbr0_disable.
>>
>> That also means we have to invalidate the reserved ASID so as to not
>> accidentally hit while uaccess is disabled.
>
> The CPU in question (Falkor v1) has hardware PAN support. Do we need
> to worry about including the workaround in the SW PAN code in that case?
Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
that case too, and hope that people do enable the HW version.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-01-31 17:56 ` Marc Zyngier
@ 2017-02-01 16:29 ` Christopher Covington
-1 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-02-01 16:29 UTC (permalink / raw)
To: Marc Zyngier, Mark Rutland, Catalin Marinas, Will Deacon
Cc: Paolo Bonzini, Radim Krčmář,
Christoffer Dall, kvm, linux-arm-kernel, kvmarm, linux-kernel,
shankerd, timur, Jonathan Corbet, linux-doc, Jon Masters,
Neil Leeder, Mark Langsdorf
On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> On 31/01/17 17:48, Christopher Covington wrote:
>> On 01/31/2017 07:37 AM, Mark Rutland wrote:
>>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>>>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>>>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>>>> is triggered, page table entries using the new translation table base
>>>> address (BADDR) will be allocated into the TLB using the old ASID. All
>>>> circumstances leading to the incorrect ASID being cached in the TLB arise
>>>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>>>> operation is in the process of performing a translation using the specific
>>>> TTBRx_EL1 being written, and the memory operation uses a translation table
>>>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>>>> ASID is not subject to this erratum because hardware is prohibited from
>>>> performing translations from an out-of-context translation regime.
>>>>
>>>> Consider the following pseudo code.
>>>>
>>>> write new BADDR and ASID values to TTBRx_EL1
>>>>
>>>> Replacing the above sequence with the one below will ensure that no TLB
>>>> entries with an incorrect ASID are used by software.
>>>>
>>>> write reserved value to TTBRx_EL1[ASID]
>>>> ISB
>>>> write new value to TTBRx_EL1[BADDR]
>>>> ISB
>>>> write new value to TTBRx_EL1[ASID]
>>>> ISB
>>>>
>>>> When the above sequence is used, page table entries using the new BADDR
>>>> value may still be incorrectly allocated into the TLB using the reserved
>>>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>>>> tagged with the reserved ASID will never be hit by a later instruction.
>>>
>>> Based on my understanding that entries allocated to the reserved ASID
>>> will not be used for subsequent page table walks (and so we don't have
>>> asynchronous behaviour to contend with), this sounds fine to me.
>>>
>>> Thanks for taking the time to clarify the details on that.
>>>
>>>> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>>>>
>>>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>>>> ---
>>>> Documentation/arm64/silicon-errata.txt | 1 +
>>>> arch/arm64/Kconfig | 11 +++++++++++
>>>> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
>>>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>>>> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
>>>> arch/arm64/kernel/cpu_errata.c | 7 +++++++
>>>> arch/arm64/mm/context.c | 11 +++++++++++
>>>> arch/arm64/mm/proc.S | 1 +
>>>> 8 files changed, 63 insertions(+), 2 deletions(-)
>>>
>>> Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
>>> for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
>>> for the empty table in __uaccess_ttbr0_disable.
>>>
>>> That also means we have to invalidate the reserved ASID so as to not
>>> accidentally hit while uaccess is disabled.
>>
>> The CPU in question (Falkor v1) has hardware PAN support. Do we need
>> to worry about including the workaround in the SW PAN code in that case?
>
> Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> that case too, and hope that people do enable the HW version.
Okay, I'll do my best to add support for the SW PAN case. I rebased and
submitted v6 of the E1009 patch [1] so that it no longer depends on this
patch landing first, if you all are inclined to pick it up while work on
this E1003 patch continues.
1. https://patchwork.kernel.org/patch/9547923/
Thanks,
Christopher
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 16:29 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-02-01 16:29 UTC (permalink / raw)
To: linux-arm-kernel
On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> On 31/01/17 17:48, Christopher Covington wrote:
>> On 01/31/2017 07:37 AM, Mark Rutland wrote:
>>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>>>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>>>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>>>> is triggered, page table entries using the new translation table base
>>>> address (BADDR) will be allocated into the TLB using the old ASID. All
>>>> circumstances leading to the incorrect ASID being cached in the TLB arise
>>>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>>>> operation is in the process of performing a translation using the specific
>>>> TTBRx_EL1 being written, and the memory operation uses a translation table
>>>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>>>> ASID is not subject to this erratum because hardware is prohibited from
>>>> performing translations from an out-of-context translation regime.
>>>>
>>>> Consider the following pseudo code.
>>>>
>>>> write new BADDR and ASID values to TTBRx_EL1
>>>>
>>>> Replacing the above sequence with the one below will ensure that no TLB
>>>> entries with an incorrect ASID are used by software.
>>>>
>>>> write reserved value to TTBRx_EL1[ASID]
>>>> ISB
>>>> write new value to TTBRx_EL1[BADDR]
>>>> ISB
>>>> write new value to TTBRx_EL1[ASID]
>>>> ISB
>>>>
>>>> When the above sequence is used, page table entries using the new BADDR
>>>> value may still be incorrectly allocated into the TLB using the reserved
>>>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>>>> tagged with the reserved ASID will never be hit by a later instruction.
>>>
>>> Based on my understanding that entries allocated to the reserved ASID
>>> will not be used for subsequent page table walks (and so we don't have
>>> asynchronous behaviour to contend with), this sounds fine to me.
>>>
>>> Thanks for taking the time to clarify the details on that.
>>>
>>>> Based on work by Shanker Donthineni <shankerd@codeaurora.org>
>>>>
>>>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>>>> ---
>>>> Documentation/arm64/silicon-errata.txt | 1 +
>>>> arch/arm64/Kconfig | 11 +++++++++++
>>>> arch/arm64/include/asm/assembler.h | 23 +++++++++++++++++++++++
>>>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>>>> arch/arm64/include/asm/mmu_context.h | 8 +++++++-
>>>> arch/arm64/kernel/cpu_errata.c | 7 +++++++
>>>> arch/arm64/mm/context.c | 11 +++++++++++
>>>> arch/arm64/mm/proc.S | 1 +
>>>> 8 files changed, 63 insertions(+), 2 deletions(-)
>>>
>>> Don't we need to use pre_ttbr0_update_workaround in <asm/asm-uaccess.h>
>>> for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID
>>> for the empty table in __uaccess_ttbr0_disable.
>>>
>>> That also means we have to invalidate the reserved ASID so as to not
>>> accidentally hit while uaccess is disabled.
>>
>> The CPU in question (Falkor v1) has hardware PAN support. Do we need
>> to worry about including the workaround in the SW PAN code in that case?
>
> Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> that case too, and hope that people do enable the HW version.
Okay, I'll do my best to add support for the SW PAN case. I rebased and
submitted v6 of the E1009 patch [1] so that it no longer depends on this
patch landing first, if you all are inclined to pick it up while work on
this E1003 patch continues.
1. https://patchwork.kernel.org/patch/9547923/
Thanks,
Christopher
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 16:29 ` Christopher Covington
(?)
@ 2017-02-01 16:33 ` Will Deacon
-1 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 16:33 UTC (permalink / raw)
To: Christopher Covington
Cc: Marc Zyngier, Mark Rutland, Catalin Marinas, Paolo Bonzini,
Radim Krčmář,
Christoffer Dall, kvm, linux-arm-kernel, kvmarm, linux-kernel,
shankerd, timur, Jonathan Corbet, linux-doc, Jon Masters,
Neil Leeder, Mark Langsdorf
On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > that case too, and hope that people do enable the HW version.
>
> Okay, I'll do my best to add support for the SW PAN case. I rebased and
> submitted v6 of the E1009 patch [1] so that it no longer depends on this
> patch landing first, if you all are inclined to pick it up while work on
> this E1003 patch continues.
The alternative is not enabling SW_PAN (at runtime) if this errata is
present, along with a warning stating that hardware-PAN should be
enabled in kconfig instead. Not sure what distributions will make of that
though.
> 1. https://patchwork.kernel.org/patch/9547923/
Yup, I queued that one locally and I'll push to -next tomorrow.
Thanks,
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 16:33 ` Will Deacon
0 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 16:33 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > that case too, and hope that people do enable the HW version.
>
> Okay, I'll do my best to add support for the SW PAN case. I rebased and
> submitted v6 of the E1009 patch [1] so that it no longer depends on this
> patch landing first, if you all are inclined to pick it up while work on
> this E1003 patch continues.
The alternative is not enabling SW_PAN (at runtime) if this errata is
present, along with a warning stating that hardware-PAN should be
enabled in kconfig instead. Not sure what distributions will make of that
though.
> 1. https://patchwork.kernel.org/patch/9547923/
Yup, I queued that one locally and I'll push to -next tomorrow.
Thanks,
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 16:33 ` Will Deacon
0 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 16:33 UTC (permalink / raw)
To: Christopher Covington
Cc: Mark Langsdorf, kvm, Marc Zyngier, Catalin Marinas, timur,
Jonathan Corbet, linux-doc, linux-kernel, linux-arm-kernel,
Neil Leeder, Jon Masters, Paolo Bonzini, kvmarm
On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > that case too, and hope that people do enable the HW version.
>
> Okay, I'll do my best to add support for the SW PAN case. I rebased and
> submitted v6 of the E1009 patch [1] so that it no longer depends on this
> patch landing first, if you all are inclined to pick it up while work on
> this E1003 patch continues.
The alternative is not enabling SW_PAN (at runtime) if this errata is
present, along with a warning stating that hardware-PAN should be
enabled in kconfig instead. Not sure what distributions will make of that
though.
> 1. https://patchwork.kernel.org/patch/9547923/
Yup, I queued that one locally and I'll push to -next tomorrow.
Thanks,
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 16:33 ` Will Deacon
@ 2017-02-01 17:36 ` Catalin Marinas
-1 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 17:36 UTC (permalink / raw)
To: Will Deacon
Cc: Christopher Covington, Mark Rutland, Mark Langsdorf, kvm,
Radim Krčmář,
Marc Zyngier, timur, Jonathan Corbet, linux-doc, linux-kernel,
shankerd, linux-arm-kernel, Neil Leeder, Jon Masters,
Paolo Bonzini, kvmarm, Christoffer Dall
On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > that case too, and hope that people do enable the HW version.
> >
> > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > patch landing first, if you all are inclined to pick it up while work on
> > this E1003 patch continues.
>
> The alternative is not enabling SW_PAN (at runtime) if this errata is
> present, along with a warning stating that hardware-PAN should be
> enabled in kconfig instead. Not sure what distributions will make of that
> though.
The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
and in the absence of hardware PAN (or ARM64_PAN disabled),
cpu_do_switch_mm is no longer called for user process switching, so the
workaround is pretty much useless.
I'm ok with adding the Kconfig dependency below to
QCOM_FALKOR_ERRATUM_1003:
depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
I'm not keen on adding the workaround to the uaccess macros. They are
complex enough already and people who do want SW PAN (and single Image)
would end up with 6-8 extra unnecessary nops on each side of a uaccess
(and nops are not entirely free).
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 17:36 ` Catalin Marinas
0 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 17:36 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > that case too, and hope that people do enable the HW version.
> >
> > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > patch landing first, if you all are inclined to pick it up while work on
> > this E1003 patch continues.
>
> The alternative is not enabling SW_PAN (at runtime) if this errata is
> present, along with a warning stating that hardware-PAN should be
> enabled in kconfig instead. Not sure what distributions will make of that
> though.
The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
and in the absence of hardware PAN (or ARM64_PAN disabled),
cpu_do_switch_mm is no longer called for user process switching, so the
workaround is pretty much useless.
I'm ok with adding the Kconfig dependency below to
QCOM_FALKOR_ERRATUM_1003:
depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
I'm not keen on adding the workaround to the uaccess macros. They are
complex enough already and people who do want SW PAN (and single Image)
would end up with 6-8 extra unnecessary nops on each side of a uaccess
(and nops are not entirely free).
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 17:36 ` Catalin Marinas
(?)
@ 2017-02-01 17:41 ` Will Deacon
-1 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 17:41 UTC (permalink / raw)
To: Catalin Marinas
Cc: Christopher Covington, Mark Rutland, Mark Langsdorf, kvm,
Radim Krčmář,
Marc Zyngier, timur, Jonathan Corbet, linux-doc, linux-kernel,
shankerd, linux-arm-kernel, Neil Leeder, Jon Masters,
Paolo Bonzini, kvmarm, Christoffer Dall
On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > that case too, and hope that people do enable the HW version.
> > >
> > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > patch landing first, if you all are inclined to pick it up while work on
> > > this E1003 patch continues.
> >
> > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > present, along with a warning stating that hardware-PAN should be
> > enabled in kconfig instead. Not sure what distributions will make of that
> > though.
>
> The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> and in the absence of hardware PAN (or ARM64_PAN disabled),
> cpu_do_switch_mm is no longer called for user process switching, so the
> workaround is pretty much useless.
Oh, I see what you mean now.
> I'm ok with adding the Kconfig dependency below to
> QCOM_FALKOR_ERRATUM_1003:
>
> depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
>
> together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
That makes it look like hardware-PAN is the cause of the erratum. Maybe
just select ARM64_PAN if the erratum workaround is selected, then
runtime warning if we find that the h/w doesn't have PAN but does have
the erratum (which should never fire)?
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 17:41 ` Will Deacon
0 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 17:41 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > that case too, and hope that people do enable the HW version.
> > >
> > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > patch landing first, if you all are inclined to pick it up while work on
> > > this E1003 patch continues.
> >
> > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > present, along with a warning stating that hardware-PAN should be
> > enabled in kconfig instead. Not sure what distributions will make of that
> > though.
>
> The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> and in the absence of hardware PAN (or ARM64_PAN disabled),
> cpu_do_switch_mm is no longer called for user process switching, so the
> workaround is pretty much useless.
Oh, I see what you mean now.
> I'm ok with adding the Kconfig dependency below to
> QCOM_FALKOR_ERRATUM_1003:
>
> depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
>
> together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
That makes it look like hardware-PAN is the cause of the erratum. Maybe
just select ARM64_PAN if the erratum workaround is selected, then
runtime warning if we find that the h/w doesn't have PAN but does have
the erratum (which should never fire)?
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 17:41 ` Will Deacon
0 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 17:41 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Langsdorf, kvm, Marc Zyngier, Jon Masters, timur,
Jonathan Corbet, linux-doc, linux-kernel, kvmarm, Paolo Bonzini,
Neil Leeder, linux-arm-kernel
On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > that case too, and hope that people do enable the HW version.
> > >
> > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > patch landing first, if you all are inclined to pick it up while work on
> > > this E1003 patch continues.
> >
> > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > present, along with a warning stating that hardware-PAN should be
> > enabled in kconfig instead. Not sure what distributions will make of that
> > though.
>
> The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> and in the absence of hardware PAN (or ARM64_PAN disabled),
> cpu_do_switch_mm is no longer called for user process switching, so the
> workaround is pretty much useless.
Oh, I see what you mean now.
> I'm ok with adding the Kconfig dependency below to
> QCOM_FALKOR_ERRATUM_1003:
>
> depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
>
> together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
That makes it look like hardware-PAN is the cause of the erratum. Maybe
just select ARM64_PAN if the erratum workaround is selected, then
runtime warning if we find that the h/w doesn't have PAN but does have
the erratum (which should never fire)?
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 17:41 ` Will Deacon
(?)
@ 2017-02-01 17:49 ` Catalin Marinas
-1 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 17:49 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Mark Langsdorf, Christoffer Dall, kvm,
Radim Krčmář,
Marc Zyngier, Jon Masters, timur, Jonathan Corbet, linux-doc,
linux-kernel, kvmarm, Christopher Covington, Paolo Bonzini,
Neil Leeder, shankerd, linux-arm-kernel
On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> > On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > > that case too, and hope that people do enable the HW version.
> > > >
> > > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > > patch landing first, if you all are inclined to pick it up while work on
> > > > this E1003 patch continues.
> > >
> > > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > > present, along with a warning stating that hardware-PAN should be
> > > enabled in kconfig instead. Not sure what distributions will make of that
> > > though.
> >
> > The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> > and in the absence of hardware PAN (or ARM64_PAN disabled),
> > cpu_do_switch_mm is no longer called for user process switching, so the
> > workaround is pretty much useless.
>
> Oh, I see what you mean now.
>
> > I'm ok with adding the Kconfig dependency below to
> > QCOM_FALKOR_ERRATUM_1003:
> >
> > depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
> >
> > together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
>
> That makes it look like hardware-PAN is the cause of the erratum.
With the right Kconfig comment we could make this clearer.
> Maybe
> just select ARM64_PAN if the erratum workaround is selected, then
> runtime warning if we find that the h/w doesn't have PAN but does have
> the erratum (which should never fire)?
You still need this workaround even if you don't want any PAN (both sw
and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
a dependency. It's more like if you do need a PAN, make sure you only
use the hw one.
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 17:49 ` Catalin Marinas
0 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 17:49 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> > On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > > that case too, and hope that people do enable the HW version.
> > > >
> > > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > > patch landing first, if you all are inclined to pick it up while work on
> > > > this E1003 patch continues.
> > >
> > > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > > present, along with a warning stating that hardware-PAN should be
> > > enabled in kconfig instead. Not sure what distributions will make of that
> > > though.
> >
> > The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> > and in the absence of hardware PAN (or ARM64_PAN disabled),
> > cpu_do_switch_mm is no longer called for user process switching, so the
> > workaround is pretty much useless.
>
> Oh, I see what you mean now.
>
> > I'm ok with adding the Kconfig dependency below to
> > QCOM_FALKOR_ERRATUM_1003:
> >
> > depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
> >
> > together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
>
> That makes it look like hardware-PAN is the cause of the erratum.
With the right Kconfig comment we could make this clearer.
> Maybe
> just select ARM64_PAN if the erratum workaround is selected, then
> runtime warning if we find that the h/w doesn't have PAN but does have
> the erratum (which should never fire)?
You still need this workaround even if you don't want any PAN (both sw
and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
a dependency. It's more like if you do need a PAN, make sure you only
use the hw one.
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 17:49 ` Catalin Marinas
0 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 17:49 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Langsdorf, kvm, Marc Zyngier, Jon Masters, timur,
Jonathan Corbet, linux-doc, linux-kernel, Neil Leeder,
Paolo Bonzini, kvmarm, linux-arm-kernel
On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> > On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > > that case too, and hope that people do enable the HW version.
> > > >
> > > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > > patch landing first, if you all are inclined to pick it up while work on
> > > > this E1003 patch continues.
> > >
> > > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > > present, along with a warning stating that hardware-PAN should be
> > > enabled in kconfig instead. Not sure what distributions will make of that
> > > though.
> >
> > The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> > and in the absence of hardware PAN (or ARM64_PAN disabled),
> > cpu_do_switch_mm is no longer called for user process switching, so the
> > workaround is pretty much useless.
>
> Oh, I see what you mean now.
>
> > I'm ok with adding the Kconfig dependency below to
> > QCOM_FALKOR_ERRATUM_1003:
> >
> > depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
> >
> > together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
>
> That makes it look like hardware-PAN is the cause of the erratum.
With the right Kconfig comment we could make this clearer.
> Maybe
> just select ARM64_PAN if the erratum workaround is selected, then
> runtime warning if we find that the h/w doesn't have PAN but does have
> the erratum (which should never fire)?
You still need this workaround even if you don't want any PAN (both sw
and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
a dependency. It's more like if you do need a PAN, make sure you only
use the hw one.
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 17:49 ` Catalin Marinas
@ 2017-02-01 17:51 ` Catalin Marinas
-1 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 17:51 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Mark Langsdorf, kvm, Radim Krčmář,
Marc Zyngier, Jon Masters, timur, Jonathan Corbet, linux-doc,
linux-kernel, shankerd, Christopher Covington, Neil Leeder,
Paolo Bonzini, kvmarm, Christoffer Dall, linux-arm-kernel
On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> > > On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > > > that case too, and hope that people do enable the HW version.
> > > > >
> > > > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > > > patch landing first, if you all are inclined to pick it up while work on
> > > > > this E1003 patch continues.
> > > >
> > > > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > > > present, along with a warning stating that hardware-PAN should be
> > > > enabled in kconfig instead. Not sure what distributions will make of that
> > > > though.
> > >
> > > The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> > > and in the absence of hardware PAN (or ARM64_PAN disabled),
> > > cpu_do_switch_mm is no longer called for user process switching, so the
> > > workaround is pretty much useless.
> >
> > Oh, I see what you mean now.
> >
> > > I'm ok with adding the Kconfig dependency below to
> > > QCOM_FALKOR_ERRATUM_1003:
> > >
> > > depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
> > >
> > > together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
> >
> > That makes it look like hardware-PAN is the cause of the erratum.
>
> With the right Kconfig comment we could make this clearer.
>
> > Maybe
> > just select ARM64_PAN if the erratum workaround is selected, then
> > runtime warning if we find that the h/w doesn't have PAN but does have
> > the erratum (which should never fire)?
>
> You still need this workaround even if you don't want any PAN (both sw
> and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> a dependency. It's more like if you do need a PAN, make sure you only
> use the hw one.
Alternatively, your select idea could be refined to:
select ARM64_PAN if ARM64_SW_TTBR0_PAN
but we still need a proper comment as people would wonder what this is
for.
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 17:51 ` Catalin Marinas
0 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 17:51 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> > > On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > > > that case too, and hope that people do enable the HW version.
> > > > >
> > > > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > > > patch landing first, if you all are inclined to pick it up while work on
> > > > > this E1003 patch continues.
> > > >
> > > > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > > > present, along with a warning stating that hardware-PAN should be
> > > > enabled in kconfig instead. Not sure what distributions will make of that
> > > > though.
> > >
> > > The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> > > and in the absence of hardware PAN (or ARM64_PAN disabled),
> > > cpu_do_switch_mm is no longer called for user process switching, so the
> > > workaround is pretty much useless.
> >
> > Oh, I see what you mean now.
> >
> > > I'm ok with adding the Kconfig dependency below to
> > > QCOM_FALKOR_ERRATUM_1003:
> > >
> > > depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
> > >
> > > together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
> >
> > That makes it look like hardware-PAN is the cause of the erratum.
>
> With the right Kconfig comment we could make this clearer.
>
> > Maybe
> > just select ARM64_PAN if the erratum workaround is selected, then
> > runtime warning if we find that the h/w doesn't have PAN but does have
> > the erratum (which should never fire)?
>
> You still need this workaround even if you don't want any PAN (both sw
> and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> a dependency. It's more like if you do need a PAN, make sure you only
> use the hw one.
Alternatively, your select idea could be refined to:
select ARM64_PAN if ARM64_SW_TTBR0_PAN
but we still need a proper comment as people would wonder what this is
for.
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 17:49 ` Catalin Marinas
@ 2017-02-01 17:59 ` Will Deacon
-1 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 17:59 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Mark Langsdorf, Christoffer Dall, kvm,
Radim Krčmář,
Marc Zyngier, Jon Masters, timur, Jonathan Corbet, linux-doc,
linux-kernel, kvmarm, Christopher Covington, Paolo Bonzini,
Neil Leeder, shankerd, linux-arm-kernel
On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> > > On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > > > that case too, and hope that people do enable the HW version.
> > > > >
> > > > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > > > patch landing first, if you all are inclined to pick it up while work on
> > > > > this E1003 patch continues.
> > > >
> > > > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > > > present, along with a warning stating that hardware-PAN should be
> > > > enabled in kconfig instead. Not sure what distributions will make of that
> > > > though.
> > >
> > > The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> > > and in the absence of hardware PAN (or ARM64_PAN disabled),
> > > cpu_do_switch_mm is no longer called for user process switching, so the
> > > workaround is pretty much useless.
> >
> > Oh, I see what you mean now.
> >
> > > I'm ok with adding the Kconfig dependency below to
> > > QCOM_FALKOR_ERRATUM_1003:
> > >
> > > depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
> > >
> > > together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
> >
> > That makes it look like hardware-PAN is the cause of the erratum.
>
> With the right Kconfig comment we could make this clearer.
It's not just a comment though, the kconfig option for the workaround
will disappear from menuconfig as long as the dependencies aren't met.
The dependency is really that SW_PAN depends on !ERRATUM_1003, but that
doesn't work for the distributions.
> > Maybe
> > just select ARM64_PAN if the erratum workaround is selected, then
> > runtime warning if we find that the h/w doesn't have PAN but does have
> > the erratum (which should never fire)?
>
> You still need this workaround even if you don't want any PAN (both sw
> and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> a dependency. It's more like if you do need a PAN, make sure you only
> use the hw one.
True, in the case that all PAN options are disabled we still want this
to work. How about:
select ARM64_PAN if ARM64_SW_TTBR0_PAN
?
In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
config combination? Why not just have "PAN" that enables them both and
uses the hardware feature if it's there?
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 17:59 ` Will Deacon
0 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 17:59 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> > > On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > > > that case too, and hope that people do enable the HW version.
> > > > >
> > > > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > > > patch landing first, if you all are inclined to pick it up while work on
> > > > > this E1003 patch continues.
> > > >
> > > > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > > > present, along with a warning stating that hardware-PAN should be
> > > > enabled in kconfig instead. Not sure what distributions will make of that
> > > > though.
> > >
> > > The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> > > and in the absence of hardware PAN (or ARM64_PAN disabled),
> > > cpu_do_switch_mm is no longer called for user process switching, so the
> > > workaround is pretty much useless.
> >
> > Oh, I see what you mean now.
> >
> > > I'm ok with adding the Kconfig dependency below to
> > > QCOM_FALKOR_ERRATUM_1003:
> > >
> > > depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
> > >
> > > together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
> >
> > That makes it look like hardware-PAN is the cause of the erratum.
>
> With the right Kconfig comment we could make this clearer.
It's not just a comment though, the kconfig option for the workaround
will disappear from menuconfig as long as the dependencies aren't met.
The dependency is really that SW_PAN depends on !ERRATUM_1003, but that
doesn't work for the distributions.
> > Maybe
> > just select ARM64_PAN if the erratum workaround is selected, then
> > runtime warning if we find that the h/w doesn't have PAN but does have
> > the erratum (which should never fire)?
>
> You still need this workaround even if you don't want any PAN (both sw
> and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> a dependency. It's more like if you do need a PAN, make sure you only
> use the hw one.
True, in the case that all PAN options are disabled we still want this
to work. How about:
select ARM64_PAN if ARM64_SW_TTBR0_PAN
?
In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
config combination? Why not just have "PAN" that enables them both and
uses the hardware feature if it's there?
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 17:59 ` Will Deacon
@ 2017-02-01 18:22 ` Catalin Marinas
-1 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 18:22 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Mark Langsdorf, kvm, Radim Krčmář,
Marc Zyngier, Jon Masters, timur, Jonathan Corbet, linux-doc,
linux-kernel, shankerd, Christopher Covington, Neil Leeder,
Paolo Bonzini, kvmarm, Christoffer Dall, linux-arm-kernel
On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> > On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > > On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> > > > On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > > > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > > > > that case too, and hope that people do enable the HW version.
> > > > > >
> > > > > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > > > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > > > > patch landing first, if you all are inclined to pick it up while work on
> > > > > > this E1003 patch continues.
> > > > >
> > > > > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > > > > present, along with a warning stating that hardware-PAN should be
> > > > > enabled in kconfig instead. Not sure what distributions will make of that
> > > > > though.
> > > >
> > > > The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> > > > and in the absence of hardware PAN (or ARM64_PAN disabled),
> > > > cpu_do_switch_mm is no longer called for user process switching, so the
> > > > workaround is pretty much useless.
> > >
> > > Oh, I see what you mean now.
> > >
> > > > I'm ok with adding the Kconfig dependency below to
> > > > QCOM_FALKOR_ERRATUM_1003:
> > > >
> > > > depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
> > > >
> > > > together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
> > >
> > > That makes it look like hardware-PAN is the cause of the erratum.
> >
> > With the right Kconfig comment we could make this clearer.
>
> It's not just a comment though, the kconfig option for the workaround
> will disappear from menuconfig as long as the dependencies aren't met.
> The dependency is really that SW_PAN depends on !ERRATUM_1003, but that
> doesn't work for the distributions.
I agree.
> > > Maybe
> > > just select ARM64_PAN if the erratum workaround is selected, then
> > > runtime warning if we find that the h/w doesn't have PAN but does have
> > > the erratum (which should never fire)?
> >
> > You still need this workaround even if you don't want any PAN (both sw
> > and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> > a dependency. It's more like if you do need a PAN, make sure you only
> > use the hw one.
>
> True, in the case that all PAN options are disabled we still want this
> to work. How about:
>
> select ARM64_PAN if ARM64_SW_TTBR0_PAN
As I replied to myself, the above would work for me as well, so let's go
for this.
> In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
> config combination? Why not just have "PAN" that enables them both and
> uses the hardware feature if it's there?
Because SW PAN has a non-trivial performance hit. You would enable SW
PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
and I wouldn't want to miss enabling it in a single Image supporting
ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 18:22 ` Catalin Marinas
0 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 18:22 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> > On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > > On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
> > > > On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
> > > > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
> > > > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote:
> > > > > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
> > > > > > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
> > > > > > > that case too, and hope that people do enable the HW version.
> > > > > >
> > > > > > Okay, I'll do my best to add support for the SW PAN case. I rebased and
> > > > > > submitted v6 of the E1009 patch [1] so that it no longer depends on this
> > > > > > patch landing first, if you all are inclined to pick it up while work on
> > > > > > this E1003 patch continues.
> > > > >
> > > > > The alternative is not enabling SW_PAN (at runtime) if this errata is
> > > > > present, along with a warning stating that hardware-PAN should be
> > > > > enabled in kconfig instead. Not sure what distributions will make of that
> > > > > though.
> > > >
> > > > The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
> > > > and in the absence of hardware PAN (or ARM64_PAN disabled),
> > > > cpu_do_switch_mm is no longer called for user process switching, so the
> > > > workaround is pretty much useless.
> > >
> > > Oh, I see what you mean now.
> > >
> > > > I'm ok with adding the Kconfig dependency below to
> > > > QCOM_FALKOR_ERRATUM_1003:
> > > >
> > > > depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN
> > > >
> > > > together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
> > >
> > > That makes it look like hardware-PAN is the cause of the erratum.
> >
> > With the right Kconfig comment we could make this clearer.
>
> It's not just a comment though, the kconfig option for the workaround
> will disappear from menuconfig as long as the dependencies aren't met.
> The dependency is really that SW_PAN depends on !ERRATUM_1003, but that
> doesn't work for the distributions.
I agree.
> > > Maybe
> > > just select ARM64_PAN if the erratum workaround is selected, then
> > > runtime warning if we find that the h/w doesn't have PAN but does have
> > > the erratum (which should never fire)?
> >
> > You still need this workaround even if you don't want any PAN (both sw
> > and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> > a dependency. It's more like if you do need a PAN, make sure you only
> > use the hw one.
>
> True, in the case that all PAN options are disabled we still want this
> to work. How about:
>
> select ARM64_PAN if ARM64_SW_TTBR0_PAN
As I replied to myself, the above would work for me as well, so let's go
for this.
> In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
> config combination? Why not just have "PAN" that enables them both and
> uses the hardware feature if it's there?
Because SW PAN has a non-trivial performance hit. You would enable SW
PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
and I wouldn't want to miss enabling it in a single Image supporting
ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 18:22 ` Catalin Marinas
(?)
@ 2017-02-01 18:34 ` Will Deacon
-1 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 18:34 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, Mark Langsdorf, kvm, Radim Krčmář,
Marc Zyngier, Jon Masters, timur, Jonathan Corbet, linux-doc,
linux-kernel, shankerd, Christopher Covington, Neil Leeder,
Paolo Bonzini, kvmarm, Christoffer Dall, linux-arm-kernel
On Wed, Feb 01, 2017 at 06:22:44PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> > > On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > > > Maybe
> > > > just select ARM64_PAN if the erratum workaround is selected, then
> > > > runtime warning if we find that the h/w doesn't have PAN but does have
> > > > the erratum (which should never fire)?
> > >
> > > You still need this workaround even if you don't want any PAN (both sw
> > > and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> > > a dependency. It's more like if you do need a PAN, make sure you only
> > > use the hw one.
> >
> > True, in the case that all PAN options are disabled we still want this
> > to work. How about:
> >
> > select ARM64_PAN if ARM64_SW_TTBR0_PAN
>
> As I replied to myself, the above would work for me as well, so let's go
> for this.
>
> > In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
> > config combination? Why not just have "PAN" that enables them both and
> > uses the hardware feature if it's there?
>
> Because SW PAN has a non-trivial performance hit. You would enable SW
> PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
> and I wouldn't want to miss enabling it in a single Image supporting
> ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
>
> IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
Ok, in that case, then how about another permutation: we make
ARM64_SW_TTBR0_PAN depend on ARM64_PAN? Then when you select "PAN Support"
you get a new menu option underneath it for the emulation? I think that
solves the erratum case and the use-case above.
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 18:34 ` Will Deacon
0 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 18:34 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2017 at 06:22:44PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> > > On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > > > Maybe
> > > > just select ARM64_PAN if the erratum workaround is selected, then
> > > > runtime warning if we find that the h/w doesn't have PAN but does have
> > > > the erratum (which should never fire)?
> > >
> > > You still need this workaround even if you don't want any PAN (both sw
> > > and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> > > a dependency. It's more like if you do need a PAN, make sure you only
> > > use the hw one.
> >
> > True, in the case that all PAN options are disabled we still want this
> > to work. How about:
> >
> > select ARM64_PAN if ARM64_SW_TTBR0_PAN
>
> As I replied to myself, the above would work for me as well, so let's go
> for this.
>
> > In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
> > config combination? Why not just have "PAN" that enables them both and
> > uses the hardware feature if it's there?
>
> Because SW PAN has a non-trivial performance hit. You would enable SW
> PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
> and I wouldn't want to miss enabling it in a single Image supporting
> ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
>
> IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
Ok, in that case, then how about another permutation: we make
ARM64_SW_TTBR0_PAN depend on ARM64_PAN? Then when you select "PAN Support"
you get a new menu option underneath it for the emulation? I think that
solves the erratum case and the use-case above.
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 18:34 ` Will Deacon
0 siblings, 0 replies; 86+ messages in thread
From: Will Deacon @ 2017-02-01 18:34 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Langsdorf, kvm, Marc Zyngier, Jon Masters, timur,
Jonathan Corbet, linux-doc, linux-kernel, kvmarm, Paolo Bonzini,
Neil Leeder, linux-arm-kernel
On Wed, Feb 01, 2017 at 06:22:44PM +0000, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
> > On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> > > On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > > > Maybe
> > > > just select ARM64_PAN if the erratum workaround is selected, then
> > > > runtime warning if we find that the h/w doesn't have PAN but does have
> > > > the erratum (which should never fire)?
> > >
> > > You still need this workaround even if you don't want any PAN (both sw
> > > and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> > > a dependency. It's more like if you do need a PAN, make sure you only
> > > use the hw one.
> >
> > True, in the case that all PAN options are disabled we still want this
> > to work. How about:
> >
> > select ARM64_PAN if ARM64_SW_TTBR0_PAN
>
> As I replied to myself, the above would work for me as well, so let's go
> for this.
>
> > In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
> > config combination? Why not just have "PAN" that enables them both and
> > uses the hardware feature if it's there?
>
> Because SW PAN has a non-trivial performance hit. You would enable SW
> PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
> and I wouldn't want to miss enabling it in a single Image supporting
> ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
>
> IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
Ok, in that case, then how about another permutation: we make
ARM64_SW_TTBR0_PAN depend on ARM64_PAN? Then when you select "PAN Support"
you get a new menu option underneath it for the emulation? I think that
solves the erratum case and the use-case above.
Will
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 18:34 ` Will Deacon
@ 2017-02-01 18:38 ` Catalin Marinas
-1 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 18:38 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Mark Langsdorf, Christoffer Dall, kvm,
Radim Krčmář,
Marc Zyngier, Jon Masters, timur, Jonathan Corbet, linux-doc,
linux-kernel, kvmarm, Christopher Covington, Paolo Bonzini,
Neil Leeder, shankerd, linux-arm-kernel
On Wed, Feb 01, 2017 at 06:34:01PM +0000, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 06:22:44PM +0000, Catalin Marinas wrote:
> > On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
> > > On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> > > > On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > > > > Maybe
> > > > > just select ARM64_PAN if the erratum workaround is selected, then
> > > > > runtime warning if we find that the h/w doesn't have PAN but does have
> > > > > the erratum (which should never fire)?
> > > >
> > > > You still need this workaround even if you don't want any PAN (both sw
> > > > and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> > > > a dependency. It's more like if you do need a PAN, make sure you only
> > > > use the hw one.
> > >
> > > True, in the case that all PAN options are disabled we still want this
> > > to work. How about:
> > >
> > > select ARM64_PAN if ARM64_SW_TTBR0_PAN
> >
> > As I replied to myself, the above would work for me as well, so let's go
> > for this.
> >
> > > In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
> > > config combination? Why not just have "PAN" that enables them both and
> > > uses the hardware feature if it's there?
> >
> > Because SW PAN has a non-trivial performance hit. You would enable SW
> > PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
> > and I wouldn't want to miss enabling it in a single Image supporting
> > ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
> >
> > IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
>
> Ok, in that case, then how about another permutation: we make
> ARM64_SW_TTBR0_PAN depend on ARM64_PAN? Then when you select "PAN Support"
> you get a new menu option underneath it for the emulation? I think that
> solves the erratum case and the use-case above.
The problem is that ARM64_PAN is an ARMv8.1 feature and currently
grouped accordingly in Kconfig. ARM64_SW_TTBR0_PAN is complementary (and
even not recommended on ARMv8.1). We can do this if we break the ARMv8.x
feature grouping but just for this erratum, I don't think it's worth.
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-01 18:38 ` Catalin Marinas
0 siblings, 0 replies; 86+ messages in thread
From: Catalin Marinas @ 2017-02-01 18:38 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 01, 2017 at 06:34:01PM +0000, Will Deacon wrote:
> On Wed, Feb 01, 2017 at 06:22:44PM +0000, Catalin Marinas wrote:
> > On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
> > > On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
> > > > On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
> > > > > Maybe
> > > > > just select ARM64_PAN if the erratum workaround is selected, then
> > > > > runtime warning if we find that the h/w doesn't have PAN but does have
> > > > > the erratum (which should never fire)?
> > > >
> > > > You still need this workaround even if you don't want any PAN (both sw
> > > > and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> > > > a dependency. It's more like if you do need a PAN, make sure you only
> > > > use the hw one.
> > >
> > > True, in the case that all PAN options are disabled we still want this
> > > to work. How about:
> > >
> > > select ARM64_PAN if ARM64_SW_TTBR0_PAN
> >
> > As I replied to myself, the above would work for me as well, so let's go
> > for this.
> >
> > > In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
> > > config combination? Why not just have "PAN" that enables them both and
> > > uses the hardware feature if it's there?
> >
> > Because SW PAN has a non-trivial performance hit. You would enable SW
> > PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
> > and I wouldn't want to miss enabling it in a single Image supporting
> > ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
> >
> > IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
>
> Ok, in that case, then how about another permutation: we make
> ARM64_SW_TTBR0_PAN depend on ARM64_PAN? Then when you select "PAN Support"
> you get a new menu option underneath it for the emulation? I think that
> solves the erratum case and the use-case above.
The problem is that ARM64_PAN is an ARMv8.1 feature and currently
grouped accordingly in Kconfig. ARM64_SW_TTBR0_PAN is complementary (and
even not recommended on ARMv8.1). We can do this if we break the ARMv8.x
feature grouping but just for this erratum, I don't think it's worth.
--
Catalin
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
2017-02-01 18:38 ` Catalin Marinas
(?)
@ 2017-02-08 0:36 ` Christopher Covington
-1 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-02-08 0:36 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, Mark Langsdorf, Christoffer Dall, kvm,
Radim Krčmář,
Marc Zyngier, Jon Masters, timur, Jonathan Corbet, linux-doc,
linux-kernel, kvmarm, Paolo Bonzini, Neil Leeder, shankerd,
linux-arm-kernel
On 02/01/2017 01:38 PM, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 06:34:01PM +0000, Will Deacon wrote:
>> On Wed, Feb 01, 2017 at 06:22:44PM +0000, Catalin Marinas wrote:
>>> On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
>>>> On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
>>>>> On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
>>>>>> Maybe
>>>>>> just select ARM64_PAN if the erratum workaround is selected, then
>>>>>> runtime warning if we find that the h/w doesn't have PAN but does have
>>>>>> the erratum (which should never fire)?
>>>>>
>>>>> You still need this workaround even if you don't want any PAN (both sw
>>>>> and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
>>>>> a dependency. It's more like if you do need a PAN, make sure you only
>>>>> use the hw one.
>>>>
>>>> True, in the case that all PAN options are disabled we still want this
>>>> to work. How about:
>>>>
>>>> select ARM64_PAN if ARM64_SW_TTBR0_PAN
>>>
>>> As I replied to myself, the above would work for me as well, so let's go
>>> for this.
>>>
>>>> In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
>>>> config combination? Why not just have "PAN" that enables them both and
>>>> uses the hardware feature if it's there?
>>>
>>> Because SW PAN has a non-trivial performance hit. You would enable SW
>>> PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
>>> and I wouldn't want to miss enabling it in a single Image supporting
>>> ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
>>>
>>> IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
>>
>> Ok, in that case, then how about another permutation: we make
>> ARM64_SW_TTBR0_PAN depend on ARM64_PAN? Then when you select "PAN Support"
>> you get a new menu option underneath it for the emulation? I think that
>> solves the erratum case and the use-case above.
>
> The problem is that ARM64_PAN is an ARMv8.1 feature and currently
> grouped accordingly in Kconfig. ARM64_SW_TTBR0_PAN is complementary (and
> even not recommended on ARMv8.1). We can do this if we break the ARMv8.x
> feature grouping but just for this erratum, I don't think it's worth.
Thanks all. I've used "select ARM64_PAN if ARM64_SW_TTBR0_PAN" in v6.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-08 0:36 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-02-08 0:36 UTC (permalink / raw)
To: linux-arm-kernel
On 02/01/2017 01:38 PM, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 06:34:01PM +0000, Will Deacon wrote:
>> On Wed, Feb 01, 2017 at 06:22:44PM +0000, Catalin Marinas wrote:
>>> On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
>>>> On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
>>>>> On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
>>>>>> Maybe
>>>>>> just select ARM64_PAN if the erratum workaround is selected, then
>>>>>> runtime warning if we find that the h/w doesn't have PAN but does have
>>>>>> the erratum (which should never fire)?
>>>>>
>>>>> You still need this workaround even if you don't want any PAN (both sw
>>>>> and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
>>>>> a dependency. It's more like if you do need a PAN, make sure you only
>>>>> use the hw one.
>>>>
>>>> True, in the case that all PAN options are disabled we still want this
>>>> to work. How about:
>>>>
>>>> select ARM64_PAN if ARM64_SW_TTBR0_PAN
>>>
>>> As I replied to myself, the above would work for me as well, so let's go
>>> for this.
>>>
>>>> In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
>>>> config combination? Why not just have "PAN" that enables them both and
>>>> uses the hardware feature if it's there?
>>>
>>> Because SW PAN has a non-trivial performance hit. You would enable SW
>>> PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
>>> and I wouldn't want to miss enabling it in a single Image supporting
>>> ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
>>>
>>> IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
>>
>> Ok, in that case, then how about another permutation: we make
>> ARM64_SW_TTBR0_PAN depend on ARM64_PAN? Then when you select "PAN Support"
>> you get a new menu option underneath it for the emulation? I think that
>> solves the erratum case and the use-case above.
>
> The problem is that ARM64_PAN is an ARMv8.1 feature and currently
> grouped accordingly in Kconfig. ARM64_SW_TTBR0_PAN is complementary (and
> even not recommended on ARMv8.1). We can do this if we break the ARMv8.x
> feature grouping but just for this erratum, I don't think it's worth.
Thanks all. I've used "select ARM64_PAN if ARM64_SW_TTBR0_PAN" in v6.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
@ 2017-02-08 0:36 ` Christopher Covington
0 siblings, 0 replies; 86+ messages in thread
From: Christopher Covington @ 2017-02-08 0:36 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Langsdorf, kvm, Marc Zyngier, Jon Masters, timur,
Jonathan Corbet, linux-doc, linux-kernel, Neil Leeder,
Paolo Bonzini, kvmarm, linux-arm-kernel
On 02/01/2017 01:38 PM, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 06:34:01PM +0000, Will Deacon wrote:
>> On Wed, Feb 01, 2017 at 06:22:44PM +0000, Catalin Marinas wrote:
>>> On Wed, Feb 01, 2017 at 05:59:48PM +0000, Will Deacon wrote:
>>>> On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
>>>>> On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
>>>>>> Maybe
>>>>>> just select ARM64_PAN if the erratum workaround is selected, then
>>>>>> runtime warning if we find that the h/w doesn't have PAN but does have
>>>>>> the erratum (which should never fire)?
>>>>>
>>>>> You still need this workaround even if you don't want any PAN (both sw
>>>>> and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
>>>>> a dependency. It's more like if you do need a PAN, make sure you only
>>>>> use the hw one.
>>>>
>>>> True, in the case that all PAN options are disabled we still want this
>>>> to work. How about:
>>>>
>>>> select ARM64_PAN if ARM64_SW_TTBR0_PAN
>>>
>>> As I replied to myself, the above would work for me as well, so let's go
>>> for this.
>>>
>>>> In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
>>>> config combination? Why not just have "PAN" that enables them both and
>>>> uses the hardware feature if it's there?
>>>
>>> Because SW PAN has a non-trivial performance hit. You would enable SW
>>> PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
>>> and I wouldn't want to miss enabling it in a single Image supporting
>>> ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
>>>
>>> IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
>>
>> Ok, in that case, then how about another permutation: we make
>> ARM64_SW_TTBR0_PAN depend on ARM64_PAN? Then when you select "PAN Support"
>> you get a new menu option underneath it for the emulation? I think that
>> solves the erratum case and the use-case above.
>
> The problem is that ARM64_PAN is an ARMv8.1 feature and currently
> grouped accordingly in Kconfig. ARM64_SW_TTBR0_PAN is complementary (and
> even not recommended on ARMv8.1). We can do this if we break the ARMv8.x
> feature grouping but just for this erratum, I don't think it's worth.
Thanks all. I've used "select ARM64_PAN if ARM64_SW_TTBR0_PAN" in v6.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 86+ messages in thread