Re: [Qemu-devel] Minimal ARM LPAE support

[Peter Maydell]

On 13 March 2012 14:51, Alexey Starikovskiy <address@hidden> wrote:
> On 03/13/2012 06:21 PM, Peter Maydell wrote:
>>
>> On 13 March 2012 11:19, Alexey Starikovskiy<address@hidden>  wrote:
>>>
>>> Minimal ARM LPAE support. Sufficient to boot Linux kernel on vexpress-a15
>>
>> This is missing chunks of what LPAE ought to mean, which is dubious,
>> and it doesn't state clearly what it is missing, which is definitely
>> a problem.
>>
> I've cut out Virtualization, TrustZone, shareable/cache attributes.
> Also, as you've mentioned later, phys_address is still 32 bits, so we really
> can't get more memory than before.

I really meant, what bits of LPAE are you missing?

To pick an example entirely at random, LPAE implies that the DBGDRAR is
now 64 bits. Another: LPAE implies PXN in the short descriptor translation
table format. (PXN should have its own feature bit as it's permitted
for non-LPAE cores too.)

The ARM ARM has a convenient list in section B1.6.

> As it is a helper for MCRR, only crm and opc1 fields are present in
> instruction. All allowed values are checked.

Oops, yes. Sorry about the incorrect complaint, I'd thought MCRR had
crn as well.

>> This change seems to drop the MCRR block cache op handling and I don't
>> see anything elsewhere which implements it. This will presumably break
>> some CPU/guest combination.
>
> Do you have any pointer on that exactly did we try to emulate here?

No. You'll need to check the TRMs for every CPU core we claim to
emulate and the ARM ARM (including the ARMv6 and ARMv5 versions
as well as the current revision). Yes, this is a really painful
chore. You'll also need to try to round up some images so you can
test at least a handful of them.

(I've been ploughing through this for the 32 bit registers as part
of trying to convert them to a more data driven implementation.)

I suggest you split your patches up a bit, maybe:
 * framework for 64 bit cp15 registers
 * handle block cache ops there rather than special case
 * lpae changes

>> More general question -- should we move target_phys_addr_t to a 64
>> bit type?
>
> It could be done later on, for now it works as is. Making it 64 bit breaks
> DMA in pxa*, so I'm not sure how to do that properly.

We should probably fix anything that would break on a 64 bit
target_phys_addr_t anyway, there was a discussion a while back
about just shifting everything in qemu to 64 bit regardless.

-- PMM