qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 11/21] target-arm: Update generic cpreg code for


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH 11/21] target-arm: Update generic cpreg code for AArch64
Date: Sat, 21 Dec 2013 07:41:51 +1000

On Sat, Dec 21, 2013 at 4:16 AM, Peter Maydell <address@hidden> wrote:
> On 20 December 2013 10:00, Peter Maydell <address@hidden> wrote:
>> I'll have a think about this, because there are some wrinkles relating
>> to reset that might be usefully solved this way.
>
> So my conclusion here is that really this boils down to how we
> want to deal with sysregs for AArch64 capable CPUs in general.
> There are two models I can think of:
>
> Option 1:
>  * we provide new reginfo definitions that describe the AArch64
>    views of the system registers
>  * for the AArch32 views, we just fall through and use the existing
>    definitions we've written for AArch32-only CPUs
>
> Option 2:
>  * we provide new reginfo definitions for the AArch64 views of
>    the registers, which include annotations to say whether there
>    is an AArch32 view of this register

So to clarify, would MIDR and friends be in this bucket? And does t
obsolete the old MIDR def such there is only one CPRegInfo globally?

>  * for the few registers which aren't neatly arranged so the
>    crn/crm/opc1/opc2 line up, we just split up into a separate
>    reginfo for AArch64 and AArch32

ACK, that sounds awkward but there nothing we can do abt it. how many
are there? The few I checked always line up.

>  * register_cp_regs_for_features() has separate AArch32
>    and AArch64 versions
>

Do we need this? With this scheme its still possible to enforce
exclusivity in the CPRegInfo themselves.

> Option 1 is what my initial patch was assuming. Option 2
> is what the idea of being able to mark a reginfo as "this
> provides both AArch32 and AArch64 register views"
> implies, I think.
>
> Having thought about it a bit I actually prefer Option 2
> of these -- it means that for a 64 bit CPU the reginfo
> dealing with a particular CPUState field will be in one
> place rather than two, and we also get a chance to
> audit which cp regs go into v8 AArch64 emulated CPUs,
> so we don't leak old backwards-compatible dummy
> definitions by accident.

Agreed.

Regards,
Peter


>
> thanks
> -- PMM
>



reply via email to

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