On Tue, 7 Jan 2020 at 21:37, Beata Michalska <beata.michal...@linaro.org> wrote: > > On Tue, 7 Jan 2020 at 14:28, Peter Maydell <peter.mayd...@linaro.org> wrote: > > 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.
My point is that the kernel hasn't actually executed the instruction, though -- that's why it's given us control. It seems a bit exposing of the underlying hw mechanism for the kernel to hand control back to userspace with the vcpu state in a sort of half-way-through situation, rather than cleanly rolling it back to "this insn has not executed at all yet". thanks -- PMM
