35 lines
1.5 KiB
Plaintext
35 lines
1.5 KiB
Plaintext
![]() |
Tagged virtual addresses in AArch64 Linux
|
||
|
=========================================
|
||
|
|
||
|
Author: Will Deacon <will.deacon@arm.com>
|
||
|
Date : 12 June 2013
|
||
|
|
||
|
This document briefly describes the provision of tagged virtual
|
||
|
addresses in the AArch64 translation system and their potential uses
|
||
|
in AArch64 Linux.
|
||
|
|
||
|
The kernel configures the translation tables so that translations made
|
||
|
via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
|
||
|
the virtual address ignored by the translation hardware. This frees up
|
||
|
this byte for application use, with the following caveats:
|
||
|
|
||
|
(1) The kernel requires that all user addresses passed to EL1
|
||
|
are tagged with tag 0x00. This means that any syscall
|
||
|
parameters containing user virtual addresses *must* have
|
||
|
their top byte cleared before trapping to the kernel.
|
||
|
|
||
|
(2) Tags are not guaranteed to be preserved when delivering
|
||
|
signals. This means that signal handlers in applications
|
||
|
making use of tags cannot rely on the tag information for
|
||
|
user virtual addresses being maintained for fields inside
|
||
|
siginfo_t. One exception to this rule is for signals raised
|
||
|
in response to debug exceptions, where the tag information
|
||
|
will be preserved.
|
||
|
|
||
|
(3) Special care should be taken when using tagged pointers,
|
||
|
since it is likely that C compilers will not hazard two
|
||
|
addresses differing only in the upper bits.
|
||
|
|
||
|
The architecture prevents the use of a tagged PC, so the upper byte will
|
||
|
be set to a sign-extension of bit 55 on exception return.
|