qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 06/11] target/arm: Reset btype for direct branch


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 06/11] target/arm: Reset btype for direct branches and syscalls
Date: Tue, 29 Jan 2019 09:57:29 +0000

On Mon, 28 Jan 2019 at 21:28, Richard Henderson
<address@hidden> wrote:
>
> On 1/22/19 6:12 AM, Peter Maydell wrote:
> > On Thu, 10 Jan 2019 at 12:17, Richard Henderson
> > <address@hidden> wrote:
> >>
> >> This is all of the non-exception cases of DISAS_NORETURN.
> >
> > What about the gen_helper_exit_atomic() exit cases ?
>
> In that case we are going to re-execute the same insn with a different
> translation, so we do not want to change btype.
>
> (Although I'm not sure how the guest could tell.  Given where we check for
> btype mismatch, we would recognize the BTI exception before getting into the
> ldst_ex path that generates the ATOMIC exception.  So any DataAbort exception
> that the atomic insn itself might generate must also have BTYPE == 0.)

Yeah, I was mostly asking because they're the other
DISAS_NORETURN cases and they're neither changed in the
patch nor mentioned as special cases in the commit message.

> > The advantage of picking the other choice (SPSR_ELx.BTYPE ==
> > PSTATE.BTYPE) is that it means that the behaviour is identical
> > for all exceptions (async or sync of any type) and we don't
> > do the work of clearing the BTYPE field (which will happen
> > potentially in "normal" guest code if we're not in a guarded page,
> > I think).
>
> Well, BTYPE is in the TB flags, so we know it's already zero in that case, so
> there's no extra work.

It's not zero if we just did a BR Xn to get to this SVC insn, is it?

thanks
-- PMM



reply via email to

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