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

[Andrew Pinski <pinskia at gmail dot com>]

On Tue, Apr 24, 2018 at 4:41 PM, Omair Javaid <omair.javaid@linaro.org> wrote:
> 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?

YES.  52bit VA userspace addresses are coming soon.

Thanks,
Andrew

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