qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 18/21] target-arm: switch banked CP register


From: Fedorov Sergey
Subject: Re: [Qemu-devel] [RFC PATCH 18/21] target-arm: switch banked CP registers
Date: Mon, 23 Dec 2013 11:28:16 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 12/22/2013 05:08 AM, Peter Crosthwaite wrote:
> On Sat, Dec 21, 2013 at 12:33 AM, Peter Maydell
> <address@hidden> wrote:
>> On 20 December 2013 14:12, Fedorov Sergey <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]