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: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 06/11] target/arm: Reset btype for direct branches and syscalls
Date: Mon, 28 Jan 2019 13:28:40 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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.)

>> For the rest of the synchronous exceptions, the state of
>> SPSR_ELx.BTYPE is CONSTRAINED UNPREDICTABLE.  However, it
>> makes more sense to me to have syscalls reset BTYPE.
> 
> 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.  But you're probably right about not making syscall
special.  I've removed that.


r~



reply via email to

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