qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Beata Michalska
Subject: Re: [RFC PATCH 1/1] target/arm: kvm: Handle DABT with no valid ISS
Date: Tue, 7 Jan 2020 21:37:43 +0000

On Tue, 7 Jan 2020 at 14:28, Peter Maydell <address@hidden> wrote:
>
> On Fri, 20 Dec 2019 at 20:27, Beata Michalska
> <address@hidden> 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 <address@hidden>
> > ---
> > +        /*
> > +         * 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]