On Thu, Dec 19, 2013 at 9:38 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 19 December 2013 07:27, Fedorov Sergey <s.fedo...@samsung.com> wrote: >> Yes, this banking scheme makes state changing events quite heavy. But >> maintaining the active copies allows to keep translation table walking code >> untouched. I think there is a trade-off between state changing and >> translation table walking overheads. > > We shouldn't be doing tlb walks that often that it makes a > difference whether we do env->ttbr0 or env->ttbr0[env->ns] ... > >> I think the CP banking is the most fragile thing in this patch series and >> this should become much better after review :) > > It would probably be a good idea to look at the v8 ARM ARM and > figure out how banked-for-NS/S registers should fit in with the > AArch64 vs AArch32 split. > [if you don't have a copy, it's on the ARM website: > http://infocenter.arm.com/help/topic/com.arm.doc.ddi0487a.a_errata2/index.html > you'll need to register an account on the website if you don't already > have one but it's a fairly simple "fill in the form" automated process] > > Note in particular that: > * many of the current uint32_t fields in our CPU state struct are > likely to widen to uint64_t, so the AArch64 representation is > canonical, and the AArch32 register accessors access a part > of that state (typically the lower 32 bits) > * registers which are banked S/NS in AArch32 are not necessarily > banked in AArch64 >
Adding to that, are there any other reasons to bank a register other than sec-extensions? It seems like what you have implemented here is too sec specific for simply calling it "banked" (without further clarification of what you are banking for). Regards, Peter > AArch64 support is likely to land before your TrustZone stuff > does so we need to make the two features work together cleanly. > > thanks > -- PMM >
