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

Re: [Xen-devel] [PATCH v2 1/3] xen/arm: Add 4-level page table for stage 2 translation



On Tue, Jul 15, 2014 at 7:17 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2014-05-27 at 12:16 +0530, vijay.kilari@xxxxxxxxx wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@xxxxxxxxxxxxxxxxxx>
>>
>> To support 48-bit Physical Address support, add 4-level
>> page tables for stage 2 translation.
>> With this patch stage 1 and stage 2 translation at EL2 are
>> with 4-levels
>
> I've been playing with this patch on various platforms and unfortunately
> there is a rather large snag here, AFAICT. Which is that 4-level stage 2
> pages are only available when ID_AA64MMFR0_EL1.PARange >= 44 bits, see
> table D4-5 in the ARMv8 ARM.

 I read from "Table D5-18 Properties of the address lookup levels, 4KB
granule size"
Where the lookup level and granule size details are provided. For
above 39 bit PA
zero level is used.

IMO, conversion above 40 bits, 4 levels are required. However if we use
concatenation, conversion can be managed with 3 levels.
Please see "Figure D5-8 General view of VMSAv8-64 stage 2 address translation,
4KB granule".
I think Xen is using concatenation method to handle 40 bits conversion.

>
> This means that for processors with smaller physical address ranges
> configuring VTCR_EL2.SL0 as 0b10 (starting level 0) causes translation
> fault. I'm observing this on platforms which have 40 or 42 bit PARange
> for example.
>
> This basically means that it is not possible to simply use 4-levels
> statically on arm64, which I think I may have previously asserted to you
> would be fine, sorry -- I hadn't appreciated the full implications of
> this bit of the ARM -- I was confused because SL0 is the inverse of the
> starting level it configures, so I read it as saying the maximum
> starting level was 1 or 2 for all PARanges, but actually it is either 1
> or 0 depending on the range (encoded as 1 and 2 in SL0). Sigh.
>
> Anyway, this means that if we want to support 44+-bit hardware then we
> need to dynamically switch between 3- and 4-level tables depending on
> the h/w capabilities. This is doable but a bit annoying.
>
> I know you have a platform which is 48-bit capable but can you confirm
> that there are things (peripherals, RAM, etc) mapped above the 2^40
> limit before I start to implement this?

Yes, our platform has peripherals placed above 2^40 limit. where I could
access with 48-bit support patch series

>
> Alternatively if you think my reading of the ARMv8 ARM is wrong please
> say so.
>
> I also note that different processors in a big.LITTLE system can have
> different PARanges. That's going to be fun!
>
> Ian.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.