| Message ID | 20210318174823.18066-6-peter.maydell@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm: Make M-profile VTOR loads on reset handle memory aliasin | expand |
On 3/18/21 11:48 AM, Peter Maydell wrote: > 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> > --- > target/arm/cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> r~
diff --git a/target/arm/cpu.c b/target/arm/cpu.c index ae04884408c..0dd623e5909 100644 --- a/target/arm/cpu.c +++ b/target/arm/cpu.c @@ -331,7 +331,7 @@ static void arm_cpu_reset(DeviceState *dev) /* Load the initial SP and PC from offset 0 and 4 in the vector table */ vecbase = env->v7m.vecbase[env->v7m.secure]; - rom = rom_ptr(vecbase, 8); + rom = rom_ptr_for_as(s->as, vecbase, 8); if (rom) { /* Address zero is covered by ROM which hasn't yet been * copied into physical memory.
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> --- target/arm/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)