From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNkKB-00068v-O0 for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:12:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNkK9-00067U-Rw for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:12:50 -0400 Received: from [199.232.76.173] (port=46242 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNkK8-00066z-UB for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:12:49 -0400 Received: from mx1.redhat.com ([66.187.233.31]:50541) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNkK8-00087a-MZ for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:12:48 -0400 Date: Tue, 29 Jul 2008 09:12:43 +0100 From: "Daniel P. Berrange" Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 1/7] xen: groundwork for xen support Message-ID: <20080729081243.GH32498@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <488EC8D9.9060705@redhat.com> Content-Transfer-Encoding: quoted-printable Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, Samuel Thibault On Tue, Jul 29, 2008 at 09:38:01AM +0200, Gerd Hoffmann wrote: > Samuel Thibault wrote: > > Anthony Liguori, le Mon 28 Jul 2008 09:04:54 -0500, a =E9crit : > >>> +/* xen_machine.c */ > >>> +extern QEMUMachine xenpv_machine; > >>> +extern QEMUMachine xenfv_machine; > >> Why does xenfv need its own machine type? > >=20 > > IIRC that's at least because it adds its own Xen platform -specific P= CI card. >=20 > That is only one tiny bit of the differences between paravirtual and > fully virtualized machines, there is plenty more. The question is > whenever qemu should try figure itself whenever the virtual machine it > serves is fully virtualized or whenever we'll explicitly tell it qemu. >=20 > I think it is better to explicitly tell qemu whenever we want create a > paravirtual or a full virtualized machine. First, because this is how > it is handled right now in xen (via -M [ xenpv | xenfv ] ), and second, > it leaves the door open to have qemu also create the domain. 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'. Thus I think its better to keep them explicitly separate - they call out to shared code where needed anyway, so there's no serious code duplication problem there. Daniel --=20 |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange= / :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 950= 5 :|