On 28 Apr 2022, at 11:34, Alex Bennée alex.bennee@linaro.org wrote:
When we introduced FEAT_LPA to QEMU's -cpu max we discovered older kernels had a bug where the physical address was copied directly from ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits the same error by blindly copying across the max supported range.
Unsurprisingly when the page tables aren't set up for these greater ranges hilarity ensues and the hypervisor crashes fairly early on in the boot-up sequence. This happens when we write to the control register in enable_mmu().
Attempt to fix this the same way as the Linux kernel does by gating PARange to the maximum the hypervisor can handle. I also had to fix up code in p2m which panics when it sees an "invalid" entry in PARange.
Signed-off-by: Alex Bennée alex.bennee@linaro.org Cc: Richard Henderson richard.henderson@linaro.org Cc: Stefano Stabellini sstabellini@kernel.org Cc: Julien Grall julien@xen.org Cc: Volodymyr Babchuk Volodymyr_Babchuk@epam.com Cc: Bertrand Marquis bertrand.marquis@arm.com
v2
- clamp p2m_ipa_bits = PADDR_BIT instead
Hi Alex,
I’ve tested the patch on fvp and Xen+Dom0 runs fine.
Tested-by: Luca Fancellu luca.fancellu@arm.com
Cheers, Luca