From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JISo3-0000sm-Ef for qemu-devel@nongnu.org; Fri, 25 Jan 2008 12:57:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JISny-0000rM-Sc for qemu-devel@nongnu.org; Fri, 25 Jan 2008 12:57:34 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JISny-0000rG-Jm for qemu-devel@nongnu.org; Fri, 25 Jan 2008 12:57:30 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JISny-0004g2-6O for qemu-devel@nongnu.org; Fri, 25 Jan 2008 12:57:30 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m0PHsMD9023584 for ; Fri, 25 Jan 2008 12:54:22 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0PHs6ML085368 for ; Fri, 25 Jan 2008 10:54:19 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0PHs6Jn022110 for ; Fri, 25 Jan 2008 10:54:06 -0700 Message-ID: <479A222E.4@us.ibm.com> Date: Fri, 25 Jan 2008 11:53:50 -0600 From: Anthony Liguori MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Merging KVM QEMU changes upstream Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, kvm-devel Hi, As most probably know, the KVM project has been maintaining a QEMU tree for some time now. Beyond support for the KVM kernel interface, the tree also contains a number of useful features like live migration, virtio, and extboot. Some of these things have been posted to qemu-devel already but were not included. I would like to work on merging the KVM changes into upstream QEMU but before I started that work, I wanted to get a read on how difficult it would be. A lot of these things were designed specifically for KVM on x86. Only now are other architectures starting to be considered. Certainly, cross-architecture emulation hasn't really been considered. I wouldn't expect anything to be merged that caused a regression for cross-architecture emulation, but I don't really have the time to get a lot of the new features working for the cross-architecture case. I would expect, though, that if these things were merged, it would make it relatively easy for someone else to do that though. Is this a reasonable merge strategy? We won't introduce regressions but I can't guarantee these new things will work cross-architecture. Regards, Anthony Liguori