Re: [Xen-devel] [RFC PATCH v2 6/8] arm/mem_access: Add long-descriptor based gpt

[Sergej Proskurin <proskurin@xxxxxxxxxxxxx>]

Hi Julien,


>
>> +
>> +    const unsigned int strides[3] = {
>> +        LPAE_SHIFT_4K,
>> +        LPAE_SHIFT_16K,
>> +        LPAE_SHIFT_64K
>> +    };
>
> Also, the stride can be found from the page shift. So I am not
> convinced you need that.

Sure, but don't you think it is cleaner doing it that way, than
subtracting a value from PAGE_SHIFT_* although we have already a
suitable define for that? Apart from that, we need to consider different
strides for different granularities, which would make it harder to
read/review if we don't use an array of strides at this point. For
instance, see the following formula to compute the starting level of the
translation tables:

level = 4 - DIV_ROUND_UP((input_size - grainsizes[gran]), strides[gran]);

>
>> +     * implementation in ARM DDI 0487A-g J11-5739.
>> +     *
>> +     * XXX: We do not check whether the 64bit domain uses a 32-bit
>> EL0. In this
>> +     * case, we need to set topbit to 31, as well.
> I think checking 32-bit EL0 is straigh-forward enough to get it done
> now. Have a look at psr_most_is_32bit.

Apparently, I have misunderstood the comment in the AddrTop pseudo-code
implementation. So, we don't need to check whether EL0 is running in
AArch32 as long as EL1 runs in AArch64. In this way, the GVA's of EL0
would be simply zero-extended to 64 bits (i.e., according to DDI 0487B-a
J1-6066, as far as I understand, we would use the AArch64 translation
regime for AArch64 EL1 and AArch32 EL0). It makes sense as EL1 would
otherwise need to be translated differently (i.e. EL0 using the AArch32
translation and EL1 using the AArch64 format).

Cheers,
~Sergej


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