On 4 June 2015 at 18:54, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote:
> On Mon, Jun 1, 2015 at 11:48 AM, Peter Maydell <peter.mayd...@linaro.org>
> wrote:
>>>
>>> -static const ARMCPRegInfo vmsa_cp_reginfo[] = {
>>> +static const ARMCPRegInfo vmsa_pmsa_cp_reginfo[] = {
>>> { .name = "DFSR", .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 0,
>>> .access = PL1_RW, .type = ARM_CP_ALIAS,
>>> .bank_fieldoffsets = { offsetoflow32(CPUARMState, cp15.dfsr_s),
>>> @@ -1856,6 +1856,14 @@ static const ARMCPRegInfo vmsa_cp_reginfo[] = {
>>> .access = PL1_RW, .resetvalue = 0,
>>> .bank_fieldoffsets = { offsetoflow32(CPUARMState, cp15.ifsr_s),
>>> offsetoflow32(CPUARMState, cp15.ifsr_ns) } },
>>> + { .name = "DFAR", .cp = 15, .opc1 = 0, .crn = 6, .crm = 0, .opc2 = 0,
>>> + .access = PL1_RW, .resetvalue = 0,
>>> + .bank_fieldoffsets = { offsetof(CPUARMState, cp15.dfar_s),
>>> + offsetof(CPUARMState, cp15.dfar_ns) } },
>>
>> Can you move the FAR_EL1 reginfo as well, please? They should stay
>> together because they're the 32 and 64 bit versions of the same
>> register.
>>
>
> Done.
>
>> (Aside: probably there's a missing ALIAS mark.)
>>
>
> I'm not sure of the full impact of this change. Who should be the
> aliaser and aliasee? I have left it out for the moment.
The rule is that coprocessor state should be transmitted once, which
means that if we have two reginfo structs referring to (parts of)
the same underlying data, we mark one as ALIAS so it's not transferred.
The approach we've taken is that the 64-bit version is the "master"
and the 32-bit version is the alias. (Even a 32-bit CPU will have
the 64-bit regdefs, they just aren't guest visible so they end up
just acting as the means for migrating the cpreg state.)
Looking more closely, though, the FARs have a complicated setup where
the secure banked versions are aliased to FAR_EL2, which might not
exist in some configs. That's a bit weird and is probably why they're
not marked ALIAS. I think transferring the state twice should be pretty
harmless, so leave it as it is for now. I may get back to looking at
whether this is the best thing (or more likely may not...)
thanks
-- PMM
