From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq08t-0000HV-Tf for qemu-devel@nongnu.org; Wed, 06 May 2015 10:17:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yq08o-0007Hf-W4 for qemu-devel@nongnu.org; Wed, 06 May 2015 10:17:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35098) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq08o-0007HZ-Mw for qemu-devel@nongnu.org; Wed, 06 May 2015 10:17:38 -0400 Message-ID: <554A2274.6060206@redhat.com> Date: Wed, 06 May 2015 16:17:24 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <55490142.5030901@twiddle.net> <554A2155.5070103@twiddle.net> In-Reply-To: <554A2155.5070103@twiddle.net> 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: Richard Henderson , Peter Crosthwaite Cc: Peter Maydell , "claudio.fontana" , Peter Crosthwaite , Stefano Stabellini , Alexander Graf , QEMU Developers , Peter Crosthwaite , "Edgar E. Iglesias" On 06/05/2015 16:12, Richard Henderson 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. > > What I don't know is if we can, at the moment, canonicalize on TB flags. If > the monitor were to use cpu_get_tb_cpu_state, I know it would work when using > TCG, but I don't know if we keep all the same data up-to-date in KVM or XEN modes. We do for KVM. As far as I know, Xen doesn't have CPU state at all, not even in fully-virtualized mode. The CPU state is held (and serialized during migration) by the hypervisor. Paolo