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. Chase IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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/D7163164-6A8C-4704-9E08-CB0E97BBCCF4%40arm.com.
