arm64: consolidate context ID for 8-bit ASIDs

When a CPU uses 8 bits of ASID, software should write the top 8 bits of TTB registers and TLBI commands as 0. Currently, we put the generation field right above the ASIDs, which leads to writing it into TTB and TLBIs. Hardware is supposed to always ignore those bits, but we shouldn't rely on that.

Always use bits [63:16] of context.id for the generation number, and keep bits [15:8] as zero when using 8-bit ASIDs.

---
 arch/arm64/mm/context.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

index b7b3978..090bf88 100644
@@ -38,8 +38,9 @@ static DEFINE_PER_CPU(u64, reserved_asids);
 static cpumask_t tlb_flush_pending;
 
 #define ASID_MASK		(~GENMASK(asid_bits - 1, 0))
-#define ASID_FIRST_VERSION	(1UL << asid_bits)
-#define NUM_USER_ASIDS		ASID_FIRST_VERSION
+#define GENERATION_SHIFT	16
+#define ASID_FIRST_VERSION	(1UL << GENERATION_SHIFT)
+#define NUM_USER_ASIDS		(1UL << asid_bits)
 
 /* Get the ASIDBits supported by the current CPU */
 static u32 get_cpu_asid_bits(void)

2.8.3

During a rollover, we mark the active ASID on each CPU as reserved, before allocating a new ID for the task that caused the rollover. This means that with N CPUs, we can only guarantee the new task to obtain a valid ASID if we have at least N+1 ASIDs. Update this limit in the initcall check.

Note that this restriction was introduced by commit 8e648066 on the arch/arm side, which disallow re-using the previously active ASID on the local CPU, as it would introduce a TLB race.

In addition, we only dispose of NUM_USER_ASIDS-1, since ASID 0 is reserved. Add this restriction as well.

---
 arch/arm64/mm/context.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

index 090bf88..036c44d 100644
@@ -180,7 +180,7 @@ static u64 new_context(struct mm_struct *mm, unsigned int cpu)
 						 &asid_generation);
 	flush_context(cpu);
 
-	/* We have at least 1 ASID per CPU, so this will always succeed */
+	/* We have more ASIDs than CPUs, so this will always succeed */
 	asid = find_next_zero_bit(asid_map, NUM_USER_ASIDS, 1);
 
 set_asid:

@@ -228,8 +228,11 @@ switch_mm_fastpath:
 static int asids_init(void)
 {
 	asid_bits = get_cpu_asid_bits();
-	/* If we end up with more CPUs than ASIDs, expect things to crash */
-	WARN_ON(NUM_USER_ASIDS < num_possible_cpus());
+	/*
+	 * Expect allocation after rollover to fail if we don't have@least
+	 * one more ASID than CPUs. ASID #0 is reserved for init_mm.
+	 */
+	WARN_ON(NUM_USER_ASIDS - 1 <= num_possible_cpus());
 	atomic64_set(&asid_generation, ASID_FIRST_VERSION);
 	asid_map = kzalloc(BITS_TO_LONGS(NUM_USER_ASIDS) * sizeof(*asid_map),
 			   GFP_KERNEL);

2.8.3

Actually, I think we can rely on this. The ARM ARM has a special exception for ASID size (there are some pending changes to this text that appear to be inconsequential to this discussion):

ASID size

[...]

When the value of TCR_EL1.AS is 0, ASID[15:8] ... Are ignored by hardware for every purpose other than reads of ID_AA64MMFR0_EL1.

Will