From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuzwC-0002mR-Qr for qemu-devel@nongnu.org; Mon, 23 Dec 2013 02:28:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vuzw6-0008BR-76 for qemu-devel@nongnu.org; Mon, 23 Dec 2013 02:28:28 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:41245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vuzw6-0008BJ-11 for qemu-devel@nongnu.org; Mon, 23 Dec 2013 02:28:22 -0500 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MY9006NO0R5WP30@mailout1.w1.samsung.com> for qemu-devel@nongnu.org; Mon, 23 Dec 2013 07:28:17 +0000 (GMT) Message-id: <52B7E610.1090500@samsung.com> Date: Mon, 23 Dec 2013 11:28:16 +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> <52B4504C.7000707@samsung.com> In-reply-to: Content-type: text/plain; charset=ISO-8859-1 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/22/2013 05:08 AM, Peter Crosthwaite wrote: > On Sat, Dec 21, 2013 at 12:33 AM, Peter Maydell > wrote: >> On 20 December 2013 14:12, Fedorov Sergey wrote: >>> 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. > Isn't that just another definition of banking? > >> Yes, I think this is generally correct. >> >>> So I think there shouldn't be "active" and "banked" fields for banked >>> AArch32 CP15 registers as in my patch. > I don't see how this extra scheme warrants the > active-set+mass-hotswapping impl. Why can the accessors just be aware > of the two different banking schemes at access time? > > 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. >> This sounds like it could work, > I largely agree, except for the need for an active set. > >> though there are some wrinkles for >> registers with readfns/writefns -- do we have extra s vs ns read/write >> functions, or just one set of functions which has to look in env->ns to >> figure out whether to use the S or NS version? > One set sounds better to me - if your resorting to open coding your > situation is probably complicated enough such that there is little you > can do in a data driven way. That said, it could be useful to define > both r.w handlers and fieldoffsets, and then the custom handlers > access do actual register read/write through a generic helper fn > (passed the CPRegInfo) that uses ->fieldoffset and is banking aware. > This handlers the common cases where helper functions are doing: > > 1: Normal access + some side effects > 2: Manipulation of the read/written value on the way in/out. > > without the need for all handlers having to open code banking functionality. > > Regards, > Peter > >>> Which branch in https://git.linaro.org/people/peter.maydell/qemu-arm.git >>> repository holds the most actual A64 support? >> It's still a work in progress so it depends what you want. >> a64-third-fourth-set is the last set of patches that went out for >> review, and should generally work for integer instructions. >> a64-working is my work-in-progress branch so it will have the >> most recent versions of everything, but it rebases frequently >> and is liable to occasionally be broken... >> >> thanks >> -- PMM >> Seems I agree with you. Best regards, Sergey Fedorov