On 16 September 2016 at 10:34, Thomas Hanson <address@hidden> wrote:
If tagged addresses are enabled, then addresses being loaded into the
PC must be cleaned up by overwriting the tag bits with either all 0's
or all 1's as specified in the ARM ARM spec. The decision process is
dependent on whether the code will be running in EL0/1 or in EL2/3 and
is controlled by a combination of Top Byte Ignored (TBI) bits in the
TCR and the value of bit 55 in the address being loaded.
TBI values are extracted from the appropriate TCR and made available
to TCG code generation routines by inserting them into the TB flags
field and then transferring them to DisasContext structure in
gen_intermediate_code_a64().
New function gen_a64_set_pc_reg() encapsulates the logic required to
determine whether clean up of the tag byte is required and then
generating the code to correctly load the PC.
In addition to those instruction which can directly load a tagged
address into the PC, there are others which increment or add a value to
the PC. If 56 bit addressing is used, these instructions can cause an
arithmetic roll-over into the tag bits. The ARM ARM specification for
handling tagged addresses requires that these cases also be addressed
by cleaning up the tag field. This work has been deferred because
there is currently no CPU model available for testing with 56 bit
addresses.
These changes are OK (other than the comments I've made on the
patches), but do not cover all the cases where values can be
loaded into the PC and may need to be cleansed of their tags.
In particular:
* on exception entry to AArch64 we may need to clean a tag out of
the vector table base address register VBAR_ELx
(in QEMU this would be in arm_cpu_do_interrupt_aarch64())
* on exception return to AArch64 we may need to clean a tag out of
the return address we got from ELR_ELx
(in QEMU, in the exception_return helper)
Note that D4.1.1 of the ARM ARM describes a potential relaxation
of the requirement that tag bits not be propagated into the PC
in the case of an illegal exception return; I recommend not
taking advantage of that relaxation unless it really does fall
out of the implementation much more trivially that way.
Watch out that you use the TBI bits for the destination EL in
each case, not the EL you start in...
thanks
-- PMM