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 Maydell
Subject: Re: [Qemu-devel] [PATCH 11/21] target-arm: Update generic cpreg code for AArch64
Date: Fri, 20 Dec 2013 10:00:47 +0000

On 20 December 2013 04:24, Peter Crosthwaite
<address@hidden> wrote:
> On Thu, Dec 19, 2013 at 7:11 PM, Peter Maydell <address@hidden> wrote:
>> Almost all the shared registers appear as 32 bit on the AArch32
>> side and 64 bits on the AArch64 side.
>
> Really? Reading v8, there are many 32 bit regs with these op0 AArch64
> encodings, for example the documentation of MIDR_EL1:
>
> Configurations
> MIDR_EL1 is architecturally mapped to AArch32 register MIDR.
> MIDR_EL1 is architecturally mapped to external register MIDR_EL1.
> Attributes
> MIDR_EL1 is a 32-bit register

"32 bit register" in the AArch64 documentation is a shorthand for
"64 bit register with the top 32 bits (currently) RES0". There are
no 32 bit system registers in AArch64 by definition, because there's
no way to load only 32 bits in or out of them: MSR/MRS are always
64 bit transfers.

> CTR, REVIDR, ID_PFRx, CSSELR, CLIDR, DACR32 to name a few more that
> are similarly documented and by no means an exhaustive list (I just
> randomly picked those from the list).

These too are all 64 bits for AArch64.

>> This means the required
>> fieldoffset value is different [or potentially so for bigendian hosts].
>> So you'd only be able to share registers which were genuinely
>> 64 bit on both sides, which are very rare. So it didn't seem worth
>> trying to accommodate it.
>>
>
> The support 32 vs 64 encoding scheme seems quite othogonal to the
> backing sotre bit width.

Well, we could add 4 to the fieldoffset for the copy of the reginfo
that we're using for the 32 bit side if TARGET_WORDS_BIGENDIAN,
I guess.

I'll have a think about this, because there are some wrinkles relating
to reset that might be usefully solved this way.

-- PMM



reply via email to

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