On 06.10.20 06:50, Jan Kiszka wrote:
> On 05.10.20 15:25, Jan Kiszka wrote:
>> On 05.10.20 15:13, Chase Conklin wrote:
>>> On 04.10.20 2:00, Jan Kiszka wrote:
>>>> From: Jan Kiszka <[email protected]>
>>>>
>>>> Array lookup is simpler, given this input-output mapping. Cover the
>>>> 52-bit case as well at this chance. This also obsoletes a couple of
>>>> PARANGE constants.
>>>>
>>>> Signed-off-by: Jan Kiszka <[email protected]>
>>>> ---
>>>> hypervisor/arch/arm64/include/asm/paging.h |  5 -----
>>>> hypervisor/arch/arm64/paging.c             | 19 +++----------------
>>>> 2 files changed, 3 insertions(+), 21 deletions(-)
>>>>
>>>> diff --git a/hypervisor/arch/arm64/include/asm/paging.h 
>>>> b/hypervisor/arch/arm64/include/asm/paging.h
>>>> index 67664efa..932dbb50 100644
>>>> --- a/hypervisor/arch/arm64/include/asm/paging.h
>>>> +++ b/hypervisor/arch/arm64/include/asm/paging.h
>>>> @@ -101,11 +101,6 @@
>>>> #define SL0_L02
>>>> #define SL0_L11
>>>> #define SL0_L20
>>>> -#define PARANGE_32B0x0
>>>> -#define PARANGE_36B0x1
>>>> -#define PARANGE_40B0x2
>>>> -#define PARANGE_42B0x3
>>>> -#define PARANGE_44B0x4
>>>> #define PARANGE_48B0x5
>>>> #define TCR_RGN_NON_CACHEABLE0x0
>>>> #define TCR_RGN_WB_WA0x1
>>>> diff --git a/hypervisor/arch/arm64/paging.c 
>>>> b/hypervisor/arch/arm64/paging.c
>>>> index db8314a6..cccce410 100644
>>>> --- a/hypervisor/arch/arm64/paging.c
>>>> +++ b/hypervisor/arch/arm64/paging.c
>>>> @@ -26,6 +26,7 @@ unsigned int cpu_parange_encoded;
>>>>   */
>>>> unsigned int get_cpu_parange(void)
>>>> {
>>>> +static const unsigned int pa_bits[] = { 32, 36, 40, 42, 44, 48, 52 };
>>>
>>> Hi Jan,
>>>
>>> I think it's safest and easiest to treat the 52-bit case as if it were
>>> 48-bit.
>>>
>>> The 52-bit case is a bit trickier than the others in that it requires a
>>> 64KB translation granule. With a 4KB translation granule, the maximum
>>> number of PA bits is 48; programming for 52-bit is treated as if it were
>>> 48-bit, so having this indicate that output addresses are 52-bit is a
>>> bit misleading.
>>>
>>> The real problem is that we set T0SZ such that the input address size is
>>> the same as the output address size. When not using a 64KB translation
>>> granule, programming a 52-bit input address size will result in
>>> translation faults.
>>
>> Ah, good to know. Will fix this. Also requires to cap
>> cpu_parange_encoded accordingly.
>>
> 
> Fixed up in next. Not resending yet as the series is large, waiting for
> further feedback first.
> 

Hmm, I just realized that we are hard-coding PARANGE_48B for the initial
page table in entry.S. Is this safe even if the supported range is smaller?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jailhouse-dev/de3b9649-6e4f-cac7-2216-8c88572b0a16%40siemens.com.

Reply via email to