On 06.10.20 14:50, Chase Conklin wrote: > On 05.10.20 23:58, Jan Kiszka wrote: >> 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? > > It should be. Recall that the issue with 52-bit was really because the > input size (VA bits) was larger than what is supported in the 4KB > translation granule; there was no functional issue with programming a > larger output size as the architecture would treat it as the largest > supported value. Here, we don't have the input size problem and, like > with the 52-bit case, the output size is treated as the largest > supported one. We'd expect an address size fault if the translation were > to produce an output address larger than the maximum supported size, but > that shouldn't happen here since we assume that the PAs for the UART and > hypervisor binary passed to init_bootstrap_pt are sane. >
Thanks for the clarification! 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/8b50894d-2ab1-85e1-bcb4-cb68616ef1f9%40siemens.com.
