Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer

[Omair Javaid <omair.javaid@linaro.org>]

On 24 April 2018 at 21:05, Daniel Thompson <daniel.thompson@linaro.org> wrote:
> On Tue, Apr 24, 2018 at 12:48:19PM +0100, Pedro Alves wrote:
>> Hi,
>>
>> On 04/20/2018 03:33 PM, Omair Javaid wrote:
>>
>> > Pointer tagging information is stored in MMU registers so in linux
>> > user-space we cannot actually read if pointer tagging is enabled or not
>> > based on register bits.
>> > JTAG debuggers should be able to read MMU registers and know whether
>> > pointer tagging is enabled or not.
>> >
>> > Rationale behind adding a separate command is to allow other application to
>> > control pointer tagging for example bare-metal (non-linux OSes) which want
>> > to use pointer tagging can enable it. I must admit I dont know of any such
>> > use-case as of now.
>>
>> Alright, that's in line with what I was thinking.  Though, bare metal
>> should have access to MMU registers too.  Ideally, things would Just Work
>> without user intervention.  But I don't mind starting by adding a
>> user-controllable knob, it might be a convenient escape hatch.  We can always
>> extend it from "on/off" -> "on/off/auto" setting, with auto the default
>> in future.
>
> For bare metal cases this is not a simple on/off control!
>
> Top byte ignore (a.k.a. pointer tagging) has separate on/off switches
> for TTBR0 (0x0 upwards) and TTBR1 (0xffffffffffff downwards) *and* we
> have to know the respective sizes of TTBR0 and TTBR1 to be sure which
> table we are using.
>
>
>> > Also I am not sure about the timeline of Linux Kernel patches going into
>> > gdb and for now I thought of this command as the most suitable option.
>> > Moreover some users might also be interested in combination where pointer
>> > tagging is enabled but Linux Kernel threads support is disabled so I
>> > thought we should give the control to the user in cases where we cannot
>> > predict use-cases.
>>
>> If everyone agrees that proper Linux kernel support benefits from
>> its own osabi setting/name, then I don't see why we couldn't start by
>> adding the osabi setting as soon as we have a use for it, even if
>> the larger Linux Kernel patches aren't ready yet.
>
> Following on from the above, for aarch64-linux-tdep we can apply domain
> knowledge regarding how things are configured. Here we know that TTBR0
> is guaranteed to have top byte ignore set, TTBR1 does not *and* we
> also know (from memory-layout.txt) that TTBR0 is sufficiently small
> that bit 55 can be used to discriminate between the two cases.
>
> In others words regardless of whether we are running at EL0 or EL1 then
> I think we should mask the top byte from pointers if and only if bit 55
> is unset, otherwise leave them as they are.

What I am understanding here is that you are basing your decision on
the fact that:

"User addresses have bits 63:48 set to 0 while the kernel addresses have
the same bits set to 1. TTBRx selection is given by bit 63 of the
virtual address."

Sounds legitimate for now but are we ever going to use more than
48-bit virtual addresses in arm64 linux?

This actually means we wont need any set pointer-tagging command and
can modify existing implementation. Sounds good?

>
>
> Daniel.