On Tue, 7 Jan 2020 at 14:28, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Fri, 20 Dec 2019 at 20:27, Beata Michalska > <beata.michal...@linaro.org> wrote: > > > > On ARMv7 & ARMv8 some load/store instructions might trigger a data abort > > exception with no valid ISS info to be decoded. The lack of decode info > > makes it at least tricky to emulate those instruction which is one of the > > (many) reasons why KVM will not even try to do so. > > > > Add suport for handling those by requesting KVM to inject external > > dabt into the quest. > > > > Signed-off-by: Beata Michalska <beata.michal...@linaro.org> > > --- > > + /* > > + * Get current PC before it will get updated to except vector entry > > + */ > > + target_ulong ins_addr = is_a64(env) ? env->pc > > + /* AArch32 mode vs T32 aka Thumb mode */ > > + : env->regs[15] - (env->thumb ? 4 : 8); > > Another thing that occurred to me last night -- why do we need > to do this adjustment of the PC/r15 ? If this is the kernel > handing control to userspace to say "this is not an instruction > I can handle, maybe you'd like to try" then surely it should > do so with the PC pointing at the offending instruction? > Similarly, if we ask the kernel to inject a data abort I > would expect that the kernel would do the work of adjusting > the PC forwards as the architecture requires when taking > the exception. >
The code here is just for easing debugging from Qemu perspective and that is the only reason why we even try to read the value of PC - it is not in any way needed by kernel to inject the abort. One can use the monitor to decode the instruction, provided it is still available at the memory location pointed by PC (handy monitor_disas) - that is why logging the address with decoded instruction, as it is the only thing that is being done here. Still the address of actually executed instruction for ARM would be PC–8 (PC–4 for Thumb) that's why the adjustment. BR Beata > thanks > -- PMM
