Commit | Line | Data |
---|---|---|
d50240a5 WD |
1 | Tagged virtual addresses in AArch64 Linux |
2 | ========================================= | |
3 | ||
4 | Author: Will Deacon <will.deacon@arm.com> | |
5 | Date : 12 June 2013 | |
6 | ||
7 | This document briefly describes the provision of tagged virtual | |
8 | addresses in the AArch64 translation system and their potential uses | |
9 | in AArch64 Linux. | |
10 | ||
11 | The kernel configures the translation tables so that translations made | |
12 | via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of | |
13 | the virtual address ignored by the translation hardware. This frees up | |
14 | this byte for application use, with the following caveats: | |
15 | ||
16 | (1) The kernel requires that all user addresses passed to EL1 | |
17 | are tagged with tag 0x00. This means that any syscall | |
18 | parameters containing user virtual addresses *must* have | |
19 | their top byte cleared before trapping to the kernel. | |
20 | ||
374ed9d1 WD |
21 | (2) Non-zero tags are not preserved when delivering signals. |
22 | This means that signal handlers in applications making use | |
23 | of tags cannot rely on the tag information for user virtual | |
24 | addresses being maintained for fields inside siginfo_t. | |
25 | One exception to this rule is for signals raised in response | |
26 | to watchpoint debug exceptions, where the tag information | |
d50240a5 WD |
27 | will be preserved. |
28 | ||
29 | (3) Special care should be taken when using tagged pointers, | |
30 | since it is likely that C compilers will not hazard two | |
374ed9d1 | 31 | virtual addresses differing only in the upper byte. |
d50240a5 WD |
32 | |
33 | The architecture prevents the use of a tagged PC, so the upper byte will | |
34 | be set to a sign-extension of bit 55 on exception return. |