|
From: | Richard Henderson |
Subject: | Re: [Qemu-devel] [PATCH v2 05/11] translate-all: exit cpu_restore_state early if translating |
Date: | Fri, 3 Mar 2017 08:46:48 +1100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
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~
[Prev in Thread] | Current Thread | [Next in Thread] |