> On 8 Feb 2024, at 10:43, Michal Orzel <[email protected]> wrote: > > When running Xen on arm32, in scenario where Xen is loaded at an address > such as boot_phys_offset >= 2GB, UBSAN reports the following: > > (XEN) UBSAN: Undefined behaviour in arch/arm/setup.c:739:58 > (XEN) pointer operation underflowed 00200000 to 86800000 > (XEN) Xen WARN at common/ubsan/ubsan.c:172 > (XEN) ----[ Xen-4.19-unstable arm32 debug=y ubsan=y Not tainted ]---- > ... > (XEN) Xen call trace: > (XEN) [<0031b4c0>] ubsan.c#ubsan_epilogue+0x18/0xf0 (PC) > (XEN) [<0031d134>] __ubsan_handle_pointer_overflow+0xb8/0xd4 (LR) > (XEN) [<0031d134>] __ubsan_handle_pointer_overflow+0xb8/0xd4 > (XEN) [<004d15a8>] start_xen+0xe0/0xbe0 > (XEN) [<0020007c>] head.o#primary_switched+0x4/0x30 > > The failure is reported for the following line: > (paddr_t)(uintptr_t)(_start + boot_phys_offset) > > This occurs because the compiler treats (ptr + size) with size bigger than > PTRDIFF_MAX as undefined behavior. To address this, switch to macro > virt_to_maddr(), given the future plans to eliminate boot_phys_offset. > > Signed-off-by: Michal Orzel <[email protected]> > ---
Hi Michal, I’ve tested this change with qemu for arm32 and arm64, looks good to me: Reviewed-by: Luca Fancellu <[email protected]> Tested-by: Luca Fancellu <[email protected]>
