On Thu, Dec 19, 2013 at 9:38 PM, Peter Maydell <address@hidden> wrote:
On 19 December 2013 07:27, Fedorov Sergey <address@hidden> 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