| Message ID | 1372080405-13365-1-git-send-email-cov@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <cov@codeaurora.org> > --- > 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
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
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
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;
Using the long-descriptor translation table format changes the layout of the CONTEXTIDR register. Signed-off-by: Christopher Covington <cov@codeaurora.org> --- arch/arm/mm/context.c | 37 +++++++++++++++++++++++++++---------- 1 file changed, 27 insertions(+), 10 deletions(-)