On Mon, 28 Jan 2019 at 21:28, Richard Henderson <[email protected]> wrote: > > On 1/22/19 6:12 AM, Peter Maydell wrote: > > On Thu, 10 Jan 2019 at 12:17, Richard Henderson > > <[email protected]> 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
