On 7 October 2014 22:50, Greg Bellows <greg.bell...@linaro.org> wrote: > I'm still trying to wrap my head around it, but I believe there are > cases where we use a different register set depending on whether a > given EL is 32 or 64-bit.
Well, if an EL is 64-bit then it sees (effectively) a totally different register set anyway. We merge together the STATE_AA64 and STATE_AA32 reginfo structures in the sourcecode[*], but the process of populating the hashtable effectively creates two disjoint sets of register info, one for STATE_AA32 and one for STATE_AA64. The 64-bit registers may have the same underlying state as one or more 32-bit registers (which the ARM ARM refers to as the registers being "architecturally mapped" to each other, and which we typically implement by pointing the fieldoffsets to the same underlying uint64_t), but they're not strictly speaking the same registers. [*] This merging is purely for convenience and to avoid having to write out multiple near-identical reginfo definitions: it's always possible to write out a non-merged equivalent pair of reginfo fields. Similarly it's always going to be possible to write out separate (STATE_AA64, STATE_AA32 BANK_S, STATE_AA32 BANK_NS) versions, we just want to be able to collapse them together into one reginfo most of the time. The other thing to watch out for is differences in what secure-SVC/etc code sees depending on whether EL3 is 32 bit or 64 bit. For instance, if EL3 is 32 bit then the SCTLR is banked, and all the non-secure privileged modes execute at EL1 and see SCTLR(NS), while the secure privileged modes execute at EL3 and see SCTLR(S). However if EL3 is 64 bit then the SCTLR is not banked, and both secure and non-secure 32 bit privileged modes execute at EL1 and see SCTLR(NS). (It's the responsibility of a 64-bit EL3 monitor to swap the contents of the EL1 registers when it switches between Secure and Nonsecure OSes.) But the USE_SECURE_REG() macro handles this correctly, so we should be good there. thanks -- PMM
