|
| 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 | + |
| 21 | + (2) Tags are not guaranteed to be preserved when delivering |
| 22 | + signals. This means that signal handlers in applications |
| 23 | + making use of tags cannot rely on the tag information for |
| 24 | + user virtual addresses being maintained for fields inside |
| 25 | + siginfo_t. One exception to this rule is for signals raised |
| 26 | + in response to debug exceptions, where the tag information |
| 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 |
| 31 | + addresses differing only in the upper bits. |
| 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. |
0 commit comments