target/arm: Make M-profile VTOR loads on reset handle memory aliasing
commit75ce72b785a7c9fcb9af2779854142a34825da59
authorPeter Maydell <peter.maydell@linaro.org>
Thu, 18 Mar 2021 17:48:23 +0000 (18 17:48 +0000)
committerPeter Maydell <peter.maydell@linaro.org>
Tue, 23 Mar 2021 11:47:31 +0000 (23 11:47 +0000)
tree0713f93030ad23b5d77af9717c2a303a7deb2858
parent1228c4596a0046b3e4e71f62773caa835dfc79df
target/arm: Make M-profile VTOR loads on reset handle memory aliasing

For Arm M-profile CPUs, on reset the CPU must load its initial PC and
SP from a vector table in guest memory.  Because we can't guarantee
reset ordering, we have to handle the possibility that the ROM blob
loader's reset function has not yet run when the CPU resets, in which
case the data in an ELF file specified by the user won't be in guest
memory to be read yet.

We work around the reset ordering problem by checking whether the ROM
blob loader has any data for the address where the vector table is,
using rom_ptr().  Unfortunately this does not handle the possibility
of memory aliasing.  For many M-profile boards, memory can be
accessed via multiple possible physical addresses; if the board has
the vector table at address X but the user's ELF file loads data via
a different address Y which is an alias to the same underlying guest
RAM then rom_ptr() will not find it.

Use the new rom_ptr_for_as() function, which deals with memory
aliasing when locating a relevant ROM blob.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210318174823.18066-6-peter.maydell@linaro.org
target/arm/cpu.c