[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
[Qemu-devel] [PATCH 07/11] target/arm: Set btype for indirect branches, Richard Henderson, 2019/01/10
[Qemu-devel] [PATCH 08/11] target/arm: Add guarded_pages cpu property for user-only, Richard Henderson, 2019/01/10
[Qemu-devel] [PATCH 09/11] target/arm: Enable BTI for -cpu max, Richard Henderson, 2019/01/10