From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLFMF-00052S-8x for qemu-devel@nongnu.org; Wed, 05 Mar 2014 12:11:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLFMA-0001TU-Cj for qemu-devel@nongnu.org; Wed, 05 Mar 2014 12:11:51 -0500 Received: from mail-la0-f50.google.com ([209.85.215.50]:42911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLFMA-0001TP-5k for qemu-devel@nongnu.org; Wed, 05 Mar 2014 12:11:46 -0500 Received: by mail-la0-f50.google.com with SMTP id y1so898750lam.37 for ; Wed, 05 Mar 2014 09:11:45 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1393347170-28502-1-git-send-email-a.rigo@virtualopensystems.com> <1393347170-28502-5-git-send-email-a.rigo@virtualopensystems.com> From: Peter Maydell Date: Wed, 5 Mar 2014 17:11:24 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [RFC 4/4] Relevant changes to enable KVM to TCG migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: alvise rigo Cc: "tech@virtualopensystems.com" , QEMU Developers On 5 March 2014 15:01, alvise rigo wrote: > So, if the processor does not start in AArch64 mode, we only add the AArch32 > version of the ARM_CP_STATE_BOTH register to the hashtable, otherwise > nothing changes and we add the two views of the register. Yes, I think if we want TCG<->KVM migration we're going to have to do something like this. It introduces complication for reset handling, though -- at the moment the aarch64 view handles reset and the aarch32 view does not. We'd need to add (back) reset information in the aarch32 views, and also raw read/write functions if needed. > This approach works only > if all the 64bit CPUs will always start in 64 bit mode. You should be checking for whether the CPU has the AARCH64 feature, which would fix that nit. > In my opinion, other solutions would require to revisit the idea of > ARM_CP_STATE_BOTH in favour of distinct definitions of the registers with > multiple views (like VBAR for AArch32 and VBAR_EL1 for AArch64). ARM_CP_STATE_BOTH is purely a shorthand to avoid having to write out two definitions when they'd be virtually the same. I don't think it adds any extra complexity that isn't already present for registers that have split definitions. In fact the split-definition registers are trickier because you end up needing all of (1) aarch64 view (2) aarch32-in-aarch64-cpu view (3) aarch32 view, which is pretty ugly. thanks -- PMM