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(-)
diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c
index 2ac3737..272c249 100644
--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -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;
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by the Linux Foundation.
Hi Christopher,
On Mon, Jun 24, 2013 at 02:26:45PM +0100, Christopher Covington wrote:
> 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
Hi Will,
On 06/24/2013 10:04 AM, Will Deacon wrote:
[...]
> 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
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
On Mon, Jun 24, 2013 at 03:39:09PM +0100, Christopher Covington wrote:
> Hi Will,
>
> On 06/24/2013 10:04 AM, Will Deacon wrote:
> [...]
>
> > 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
On 06/24/2013 10:53 AM, Will Deacon wrote:
> On Mon, Jun 24, 2013 at 03:39:09PM +0100, Christopher Covington wrote:
>> Hi Will,
>>
>> On 06/24/2013 10:04 AM, Will Deacon wrote:
>> [...]
>>
>>> 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.
But reading and implementing the architecture *is* winning! LOL. I'll file a
ticket with the architecture folks and see what they think.
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
On Mon, Jun 24, 2013 at 04:15:06PM +0100, Christopher Covington wrote:
> On 06/24/2013 10:53 AM, Will Deacon wrote:
> > On Mon, Jun 24, 2013 at 03:39:09PM +0100, Christopher Covington wrote:
> >> Hi Will,
> >>
> >> On 06/24/2013 10:04 AM, Will Deacon wrote:
> >> [...]
> >>
> >>> 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.
>
> 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
On 06/26/2013 01:11 PM, Will Deacon wrote:
> On Mon, Jun 24, 2013 at 04:15:06PM +0100, Christopher Covington wrote:
>> On 06/24/2013 10:53 AM, Will Deacon wrote:
>>> On Mon, Jun 24, 2013 at 03:39:09PM +0100, Christopher Covington wrote:
>>>> Hi Will,
>>>>
>>>> On 06/24/2013 10:04 AM, Will Deacon wrote:
>>>> [...]
>>>>
>>>>> 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.
>>
>> 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?
> 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
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.