From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNkz9-0006mX-7v for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:55:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNkz8-0006lX-25 for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:55:10 -0400 Received: from [199.232.76.173] (port=52884 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNkz7-0006lF-N6 for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:55:09 -0400 Received: from mx1.redhat.com ([66.187.233.31]:58495) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNkz7-0007Qa-9B for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:55:09 -0400 Message-ID: <488EDAE6.20904@redhat.com> Date: Tue, 29 Jul 2008 10:55:02 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 1/7] xen: groundwork for xen support References: <1217251078-6591-1-git-send-email-kraxel@redhat.com> <1217251078-6591-2-git-send-email-kraxel@redhat.com> <488DD206.8040404@codemonkey.ws> <20080728231439.GC11519@implementation> <488EC8D9.9060705@redhat.com> <20080729081243.GH32498@redhat.com> In-Reply-To: <20080729081243.GH32498@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: xen-devel@lists.xensource.com, Samuel Thibault Daniel P. Berrange wrote: > The setup process for 'xenpv' vs 'xenfv' is really very different. As I > mentioned in the other mail, 'xenfv' is really much closer to 'pc' > machine type, then 'xenpv'. Yes. I think we will keep the xenpv machine type for sure. For full virtualization it might be more useful to just use the "pc" machine type (and maybe make xenfv an alias for compatibility). >>From qemu's point of view xen and kvm are not very different: no cpu emulation needed, some chips such as apic are handled by someone else too, some additional devices might be there (xen platform device, virtio devices). So it would make sense to handle them the same way, especially once we have the qemuaccel stuff in place which will add an abstraction layer for this. cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/