qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 04/54] target/arm: remove run time semihostin


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v4 04/54] target/arm: remove run time semihosting checks
Date: Thu, 1 Aug 2019 14:36:10 +0100

On Thu, 1 Aug 2019 at 14:27, Aaron Lindsay OS
<address@hidden> wrote:
>
> On Jul 31 17:06, Alex Bennée wrote:

> > @@ -8371,11 +8315,13 @@ void arm_cpu_do_interrupt(CPUState *cs)
> >          return;
> >      }
> >
> > -    /* Semihosting semantics depend on the register width of the
> > -     * code that caused the exception, not the target exception level,
> > -     * so must be handled here.
> > +    /*
> > +     * Semihosting semantics depend on the register width of the code
> > +     * that caused the exception, not the target exception level, so
> > +     * must be handled here.
> >       */
> > -    if (check_for_semihosting(cs)) {
> > +    if (cs->exception_index == EXCP_SEMIHOST) {
> > +        handle_semihosting(cs);
> >          return;
> >      }
>
> Previously, this code would never return here if CONFIG_TCG was not
> defined because check_for_semihosting() always returned false in that
> case. Is it now true that `cs->exception_index` will never hold a value
> of EXCP_SEMIHOST if CONFIG_TCG is not defined (or that it is otherwise
> correct to return here in that case where it wasn't previously)?

It's always true that cs->exception_index can't be EXCP_SEMIHOST
here if we're not using TCG, because the only way you can get into
this function other than by using TCG is the call in
kvm_arm_handle_debug(), which sets exception_index beforehand.
More generally, we only call this function in non-TCG if we're
trying to manually configure the CPU state to simulate a guest
exception entry, and that will always be done by setting up the
exception_index to the kind of exception we're simulating before
the call. EXCP_SEMIHOST isn't a real exception so that should never
happen (you could argue that we should assert, I suppose).

thanks
-- PMM



reply via email to

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