On 12/22/2013 05:08 AM, Peter Crosthwaite wrote: > On Sat, Dec 21, 2013 at 12:33 AM, Peter Maydell > <peter.mayd...@linaro.org> wrote: >> On 20 December 2013 14:12, Fedorov Sergey <s.fedo...@samsung.com> 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
