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

[Peter Maydell]

On 20 December 2013 21:41, Peter Crosthwaite
<address@hidden> wrote:
> 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?

I think we end up with a MIDR def for old CPUs and a MIDR
for v8-and-up CPUs which handles both AArch64 and AArch32 views:
            { .name = "MIDR_EL1",
              .opc0 = 3, .crn = 0, .crm = 0, .opc1 = 0, .opc2 = 0,
              .access = PL1_R,
             .type = ARM_CP_CONST|ARM_CP_AA64|ARM_CP_AA32VIEW,
             .resetvalue = cpu->midr },

because (a) ARMv8 gets rid of the "unimplemented c15 0 0 0 x
registers read as MIDR" and (b) we can ignore the annoying
special case handling for the TI925.

(I wonder if it would be nicer to have a .state field (values
CP_STATE_AA32 == 0, CP_STATE_AA64, CP_STATE_BOTH)
rather than shoehorning it into the flags field...)

For cases where we don't have annoying v7-and-earlier legacy
to deal with we can just have one reginfo struct I think.

I think it's the weird stuff that's going to get irritating because
we're going to end up with "not for v8" logic to suppress half of
them.

>>  * 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.

Well, everything in cp14 doesn't have architectural equivalents,
for a start. In AArch32 TCMTR is crn=0 crm=0 opc1=0 opc2=2
but that is OSDTRRX_EL1 in AArch64. The TLB and cache
maintenance ops don't always match up because they've been
tidied up, I think. The docs don't make it terribly easy to compile
a list of mismatches though.

>>  * 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.

Mmm, I guess we don't really, though it does mean we're
a bit more likely to have dubious stuff lurking around in
the AArch32-visible sysregs. (OTOH that's pretty irrelevant
until we have support for either Hyp or TrustZone, since
otherwise EL1 is always AArch64...)

-- PMM