Skip to contentSkip to conversation

ARM: Add support for LPAE style CONTEXTIDR

PATCH In review Christopher Covington 2 participants 7 messages Jun 24, 2013 – Jun 26, 2013 Arm (32-bit)

lore
Share & tools
lore

Christopher Covington

author
#0 lore raw

PATCH 1/1 ARM: Add support for LPAE style CONTEXTIDR

Using the long-descriptor translation table format changes the layout of the CONTEXTIDR register.

Signed-off-by Christopher Covington <[email protected]>
---
 arch/arm/mm/context.c | 37 +++++++++++++++++++++++++++----------
 1 file changed, 27 insertions(+), 10 deletions(-)
arch/arm/mm/context.c +27 -10
index 2ac3737..272c249 100644
@@ -37,6 +37,11 @@
  *
  * In big endian operation, the two 32 bit words are swapped if accesed by
  * non 64-bit operations.
+ *
+ * The above layout is also used by ARMv7 when the short-descriptor translation
+ * table format is used, but when the long-descriptor translation table format
+ * (LPAE) is used, all 32 bits are devoted to the process identifier. (The ASID
+ * is in TTBRx.)
  */
 #define ASID_FIRST_VERSION	(1ULL << ASID_BITS)
 #define NUM_USER_ASIDS		(ASID_FIRST_VERSION - 1)

@@ -68,6 +73,13 @@ static void cpu_set_reserved_ttbr0(void)
 	: "r" (ttbl), "r" (ttbh));
 	isb();
 }
+
+static void write_contextidr(pid_t pid)
+{
+	asm volatile(
+	"	mcr	p15, 0, %0, c13, c0, 1\n"
+	: : "r" (pid));
+}
 #else
 static void cpu_set_reserved_ttbr0(void)
 {

@@ -79,20 +91,12 @@ static void cpu_set_reserved_ttbr0(void)
 	: "=r" (ttb));
 	isb();
 }
-#endif
 
-#ifdef CONFIG_PID_IN_CONTEXTIDR
-static int contextidr_notifier(struct notifier_block *unused, unsigned long cmd,
-			       void *t)
+static void write_contextidr(pid_t pid)
 {
 	u32 contextidr;
-	pid_t pid;
-	struct thread_info *thread = t;
-
-	if (cmd != THREAD_NOTIFY_SWITCH)
-		return NOTIFY_DONE;
 
-	pid = task_pid_nr(thread->task) << ASID_BITS;
+	pid <<= ASID_BITS;
 	asm volatile(
 	"	mrc	p15, 0, %0, c13, c0, 1\n"
 	"	and	%0, %0, %2\n"

@@ -100,6 +104,19 @@ static int contextidr_notifier(struct notifier_block *unused, unsigned long cmd,
 	"	mcr	p15, 0, %0, c13, c0, 1\n"
 	: "=r" (contextidr), "+r" (pid)
 	: "I" (~ASID_MASK));
+}
+#endif
+
+#ifdef CONFIG_PID_IN_CONTEXTIDR
+static int contextidr_notifier(struct notifier_block *unused, unsigned long cmd,
+			       void *t)
+{
+	struct thread_info *thread = t;
+
+	if (cmd != THREAD_NOTIFY_SWITCH)
+		return NOTIFY_DONE;
+
+	write_contextidr(task_pid_nr(thread->task));
 	isb();
 
 	return NOTIFY_OK;
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by the Linux Foundation.
#1 lore raw

Hi Christopher,

Quoted 7 lines · Christopher Covington

Using the long-descriptor translation table format changes the layout of the CONTEXTIDR register.

Signed-off-by Christopher Covington <[email protected]>
---
 arch/arm/mm/context.c | 37 +++++++++++++++++++++++++++----------
 1 file changed, 27 insertions(+), 10 deletions(-)

Hmm, I'd deliberately written the code as-is, so that debuggers wouldn't need context-sensitive parsing of the contextidr register depending on the type of page tables in use.

What's the advantage of this approach, other than you get an extra byte's worth of PID?

Will

author
#2 lore raw

Hi Will,

On 06/24/2013 10:04 AM, Will Deacon wrote:
[...]

Quoted 2 lines

What's the advantage of this approach, other than you get an extra byte's worth of PID?

In my view, the real advantage is that the the PID is located where people reading ARM Architecture Reference Manual are told they can find it.

Regards,
Christopher

Signature · 3 lines
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
#3 lore raw
Quoted 10 lines · Christopher Covington

Hi Will,

On 06/24/2013 10:04 AM, Will Deacon wrote:
[...]

Quoted 2 lines

What's the advantage of this approach, other than you get an extra byte's worth of PID?

In my view, the real advantage is that the the PID is located where people reading ARM Architecture Reference Manual are told they can find it.

Perhaps, but I'd usually expect a debugger or trace tools to do something with the PID, and they likely expect it to be shifted, so you can't really win.

Will

author
#4 lore raw
Quoted 9 lines · Will Deacon
Quoted 8 lines · Christopher Covington

Hi Will,

On 06/24/2013 10:04 AM, Will Deacon wrote:
[...]

Quoted 2 lines

What's the advantage of this approach, other than you get an extra byte's worth of PID?

Quoted 6 lines
Quoted 2 lines

In my view, the real advantage is that the the PID is located where people reading ARM Architecture Reference Manual are told they can find it.

Perhaps, but I'd usually expect a debugger or trace tools to do something with the PID, and they likely expect it to be shifted, so you can't really win.

But reading and implementing the architecture *is* winning! LOL. I'll file a ticket with the architecture folks and see what they think.

Christopher

Signature · 3 lines
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
#5 lore raw
Quoted 13 lines · Christopher Covington
Quoted 12 lines · Will Deacon
Quoted 10 lines · Christopher Covington

Hi Will,

On 06/24/2013 10:04 AM, Will Deacon wrote:
[...]

Quoted 2 lines

What's the advantage of this approach, other than you get an extra byte's worth of PID?

In my view, the real advantage is that the the PID is located where people reading ARM Architecture Reference Manual are told they can find it.

Quoted 6 lines
Quoted 3 lines

Perhaps, but I'd usually expect a debugger or trace tools to do something with the PID, and they likely expect it to be shifted, so you can't really win.

But reading and implementing the architecture *is* winning! LOL. I'll file a ticket with the architecture folks and see what they think.

...aaand that came full circle :)

I think the conclusion is that Linux PID != CONTEXTIDR.PROCID, so there's no architectural issue here. I'm just trying to keep it easy for the tools.

Will

author
#6 lore raw
Quoted 18 lines · Will Deacon
Quoted 17 lines · Christopher Covington
Quoted 15 lines · Will Deacon
Quoted 10 lines · Christopher Covington

Hi Will,

On 06/24/2013 10:04 AM, Will Deacon wrote:
[...]

Quoted 2 lines

What's the advantage of this approach, other than you get an extra byte's worth of PID?

In my view, the real advantage is that the the PID is located where people reading ARM Architecture Reference Manual are told they can find it.

Perhaps, but I'd usually expect a debugger or trace tools to do something with the PID, and they likely expect it to be shifted, so you can't really win.

Quoted 6 lines
Quoted 2 lines

But reading and implementing the architecture *is* winning! LOL. I'll file a ticket with the architecture folks and see what they think.

...aaand that came full circle :)

I think the conclusion is that Linux PID != CONTEXTIDR.PROCID.

Fair enough. What would you think then of configuration options to write other identifiers like the process group ID to the PROCID field?

Quoted 1 line

I'm just trying to keep it easy for the tools.

What tools exactly? The ones I've been working with are software model plugins supporting AArch32 and AArch64, which may be very different from the ones you're concerned about.

Thanks,
Christopher

Signature · 3 lines
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.