From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu0og-0003sY-8M for qemu-devel@nongnu.org; Fri, 20 Dec 2013 09:12:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vu0oZ-0004Ez-JS for qemu-devel@nongnu.org; Fri, 20 Dec 2013 09:12:38 -0500 Received: from mailout4.w1.samsung.com ([210.118.77.14]:46711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu0oZ-0004CW-EJ for qemu-devel@nongnu.org; Fri, 20 Dec 2013 09:12:31 -0500 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MY3007USZGT2N40@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Fri, 20 Dec 2013 14:12:29 +0000 (GMT) Message-id: <52B4504C.7000707@samsung.com> Date: Fri, 20 Dec 2013 18:12:28 +0400 From: Fedorov Sergey MIME-version: 1.0 References: <1386060535-15908-1-git-send-email-s.fedorov@samsung.com> <1386060535-15908-19-git-send-email-s.fedorov@samsung.com> <52B29FE5.40705@samsung.com> In-reply-to: Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 18/21] target-arm: switch banked CP registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Johannes Winter , Peter Crosthwaite , a.basov@samsung.com, "qemu-devel@nongnu.org Developers" On 12/19/2013 03:38 PM, Peter Maydell wrote: > On 19 December 2013 07:27, Fedorov Sergey 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 > > AArch64 support is likely to land before your TrustZone stuff > does so we need to make the two features work together cleanly. > > thanks > -- PMM > I've briefly looked at the v8 ARM ARM. As I can see there is no banked system control registers in AArch64. Seems the concept is changed to provide separate registers for each meaningful execution level. Please, correct me if I am wrong. So I think there shouldn't be "active" and "banked" fields for banked AArch32 CP15 registers as in my patch. Seems it is worth to use AArch64 view of system control registers as a basis. That means there would be separate S and NS register fields in CPU state structure that will me mapped to separate AArch64 registers. ARMCPRegInfo structure would have additional field holding NS register state filed offset for AArch32 banked registers. Which branch in https://git.linaro.org/people/peter.maydell/qemu-arm.git repository holds the most actual A64 support? Thanks! Best regards, Sergey Fedorov