Re: [RFC PATCH 1/1] target/arm: kvm: Handle DABT with no valid ISS

[Peter Maydell]

On Tue, 7 Jan 2020 at 21:37, Beata Michalska <address@hidden> wrote:
>
> On Tue, 7 Jan 2020 at 14:28, Peter Maydell <address@hidden> 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