On 03/03/2017 06:53 AM, Alex Bennée wrote:
The translation code uses cpu_ld*_code which can trigger a tlb_fill which if it fails will attempt a fault resolution. This never works during translation as the TB being generated hasn't been added yet. However with the new locking regime we end up double locking the tb_lock(). As the tcg_ctx.cpu is only set during translation we use this to short circuit the restore code and return with a fail.
We *should* have retaddr == 0 for this case, which indicates that we should not attempt to restore state. Are you seeing a non-zero value?
Hmm.. Or rather we should not have called cpu_restore_state in the first place. What is the call chain leading to this point?
Is this in fact linux-user, not softmmu, as you imply from tlb_fill? Because handle_cpu_signal will in fact pass a genuine non-zero retaddr for the SIGSEGV resulting from a cpu_ld*_code from a non-mapped address.
So... for linux-user I think the qemu_log is unnecessary -- that's just the way things are. For softmmu, I don't know what to think except that we shouldn't have gotten here.
r~
