From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq3zd-0003nW-6p for qemu-devel@nongnu.org; Wed, 06 May 2015 14:24:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yq3zZ-0007js-Tn for qemu-devel@nongnu.org; Wed, 06 May 2015 14:24:25 -0400 Received: from mail-qg0-x22e.google.com ([2607:f8b0:400d:c04::22e]:34127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq3zZ-0007jX-Of for qemu-devel@nongnu.org; Wed, 06 May 2015 14:24:21 -0400 Received: by qgfi89 with SMTP id i89so9075763qgf.1 for ; Wed, 06 May 2015 11:24:20 -0700 (PDT) Sender: Richard Henderson Message-ID: <554A5C4F.4080707@twiddle.net> Date: Wed, 06 May 2015 11:24:15 -0700 From: Richard Henderson MIME-Version: 1.0 References: <55490142.5030901@twiddle.net> <554A2155.5070103@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 6/7] monitor: "i": Add ARM specifics List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Peter Crosthwaite , "claudio.fontana" , Peter Crosthwaite , QEMU Developers , Alexander Graf , Peter Crosthwaite , "Edgar E. Iglesias" , Paolo Bonzini On 05/06/2015 08:44 AM, Peter Maydell wrote: > On 6 May 2015 at 15:12, Richard Henderson wrote: >> On 05/06/2015 12:06 AM, Peter Crosthwaite wrote: >>> Can >>> we rely on the env/CPUState always being up to date during >>> target_disas (which happens at translate time?) or will we need to go >>> field by field to make sure any env updates explicitly occur before >>> target_disas? >> >> I *think* so, but it's a near thing. The path goes >> >> tb_find_fast: >> cpu_get_tb_cpu_state, fill fill in flags for TB from current ENV state. >> tb_find_slow, >> tb_gen_code, using those same flags. >> >> There's the edge case of re-translation, but I'm going to assert that cpu mode >> changes ought not happen in that context. Doing otherwise means that the >> kernel has just switched modes, the translator has failed to end the TB, and >> the new code has faulted immediately. > > This is making the assumption that what the disassembler sees as > a "different mode" is the same as what the translator sees as a > "different mode" for which it needs to end the TB... This happens > to be true for ARM, at least, but I don't see any particular > reason why it is necessarily so for everything. I'm pretty sure it is, though. Certainly true for x86 and mips. I might call it a translator bug not to end the TB at a mode change. r~