From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKaao-0008OX-Nv for qemu-devel@nongnu.org; Mon, 03 Mar 2014 16:40:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKaaj-00086e-SJ for qemu-devel@nongnu.org; Mon, 03 Mar 2014 16:40:10 -0500 Received: from mail-la0-f44.google.com ([209.85.215.44]:51698) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKaaj-00081n-Le for qemu-devel@nongnu.org; Mon, 03 Mar 2014 16:40:05 -0500 Received: by mail-la0-f44.google.com with SMTP id hr13so5087877lab.31 for ; Mon, 03 Mar 2014 13:40:04 -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: Mon, 3 Mar 2014 21:39:43 +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 26 February 2014 10:02, alvise rigo wrote: > I agree that this is a sort of workaround, but it seems to me that a > proper solution is not possible without changing the ideas contemplated > now in the migration code. > Are we willing to accept some major changes in the code to embrace > this type of migration? Incidentally it occurred to me recently that the design we've gone for for AArch64 support (canonical copy of system register info is the AArch64 view, AArch32 register encoding is a non-migratable view onto the same underlying data) clashes rather with the idea of being able to migrate AArch32 TCG<->KVM. (Migrating AArch32 TCG to/from a KVM which is configured to run the VM in AArch32 on an AArch64 host doesn't run into the same problems, because in that case what KVM exposes to userspace will also be the AArch64 views of registers.) That was accidental, not an intentional tradeoff, but I'm not entirely sure how to reconcile things... thanks -- PMM