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

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

On 27 April 2018 at 21:28, Daniel Thompson <daniel.thompson@linaro.org> wrote:
> On Thu, Apr 26, 2018 at 01:11:04PM +0500, Omair Javaid wrote:
>> On 25 April 2018 at 13:04, Daniel Thompson <daniel.thompson@linaro.org> wrote:
>> > On Wed, Apr 25, 2018 at 04:41:40AM +0500, Omair Javaid wrote:
>> >> >> 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?
>> >
>> > Almost guaranteed I would have thought!
>> >
>> > However since the suggestion is *not* based on the assumption that bits
>> > 63:48 are zero then I don't think this matters.
>> >
>> > It is based on the assumption that bits 63:56 are unknown and cannot be
>> > used for decision making (because tag 0xff is not reserved) and also
>> > that bit 55 is not part of the VA. Bits 54:48 are not involved at all.
>> >
>> > For 52-bit VAs (and any other number of bits <56) the hueristic remains
>> > correct.
>> >
>> > For 56-bit VAs the pointer tagging feature cannot survive without being
>> > changed because with bit 55 allocated there would be no way for the
>> > hardware to discriminate between TTBR0 and TTBR1 pointers either. Thus
>> > whilst I don't deny the possibility that 56-bit addresses may eventually
>> > happen, *any* implementation of pointer tagging support in gdb would
>> > need to be updated at that point anyway.
>>
>> Above discussion seems to have sufficient points in favor of using bit
>> 55 as the indicator bit for pointer tagging on osabi Linux.
>
> When you say "use as indicator bit" is it not clear if you are still
> considering modal behaviour (pointer tagging is "on" or "off" based on
> bit 55 of one of the pointer registers) or whether you hope to move the
> masking function into the tdep code (so instead of saying all pointers
> at 56-bit, you can say all pointers need filtering in this manner).
>
> Conditional masking based on bit 55 is idempotent so there's no risk
> even if the filtering is applied multiple times at different places in
> gdb!
>
>
>> While we should also remove tagging support from non linux osabi.
>
> Agree.
>
> This is perhaps more urgent since then at least a non-Linux gdb
> can be used to debug the kernel. As things stand today no gdb-8.1
> version can be used for AArch64 kernel debugging.

I have written a patch for this issue will be posting it on for review
after testing.
Approach i am using is to sign extend address based on 55th bit after
clearing top byte.
Clearing pointer tagging from aarch64-elf and only enabling it for
aarch64-linux.

>
>
> Daniel.