From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtdpO-0000Ya-Dw for qemu-devel@nongnu.org; Thu, 19 Dec 2013 08:39:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtdpI-0004dt-An for qemu-devel@nongnu.org; Thu, 19 Dec 2013 08:39:50 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:61381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtdpI-0004cq-4P for qemu-devel@nongnu.org; Thu, 19 Dec 2013 08:39:44 -0500 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MY2000163A5C490@mailout3.w1.samsung.com> for qemu-devel@nongnu.org; Thu, 19 Dec 2013 13:39:41 +0000 (GMT) Message-id: <52B2F71C.1050202@samsung.com> Date: Thu, 19 Dec 2013 17:39:40 +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=ISO-8859-1; 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 Crosthwaite , Peter Maydell Cc: Johannes Winter , a.basov@samsung.com, "qemu-devel@nongnu.org Developers" On 12/19/2013 04:44 PM, Peter Crosthwaite wrote: > On Thu, Dec 19, 2013 at 9: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 >> > 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 I'm not sure that I understand your question correctly but I try to answer. From ARMv7 ARM document section "B3.15.3 Classification of system control registers": "Banked system control registers have two copies, one Secure and one Non-secure." I don't know any use of term "CP15 banked registers" other that related to Security Extensions. Best regards, Sergey Fedorov > >> AArch64 support is likely to land before your TrustZone stuff >> does so we need to make the two features work together cleanly. >> >> thanks >> -- PMM >>