From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNucL-0002qa-TA for qemu-devel@nongnu.org; Tue, 29 Jul 2008 15:12:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNucI-0002pD-QN for qemu-devel@nongnu.org; Tue, 29 Jul 2008 15:12:17 -0400 Received: from [199.232.76.173] (port=49574 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNucI-0002p5-Jj for qemu-devel@nongnu.org; Tue, 29 Jul 2008 15:12:14 -0400 Received: from an-out-0708.google.com ([209.85.132.245]:35884) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNucI-0007zr-Hj for qemu-devel@nongnu.org; Tue, 29 Jul 2008 15:12:14 -0400 Received: by an-out-0708.google.com with SMTP id d18so1689and.130 for ; Tue, 29 Jul 2008 12:12:13 -0700 (PDT) Message-ID: <488F6B68.4080908@codemonkey.ws> Date: Tue, 29 Jul 2008 14:11:36 -0500 From: Anthony Liguori 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> <488DDD2C.10308@redhat.com> <20080729081034.GG32498@redhat.com> <488F1BDB.90702@codemonkey.ws> <20080729142451.GZ32498@redhat.com> In-Reply-To: <20080729142451.GZ32498@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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" Cc: xen-devel@lists.xensource.com, Gerd Hoffmann , qemu-devel@nongnu.org Daniel P. Berrange wrote: > On Tue, Jul 29, 2008 at 08:32:11AM -0500, Anthony Liguori wrote: > >> Why wouldn't the Xen backends be added by appropriate -net or -drive >> options? For instance, qemu -drive file=foo.img,if=xen -net nic,model=xen >> > > That would work for certain setup tasks, but not all. In Xen's branch > of QEMU, the machine init function has to set various hypervisor > parameters which aren't directly associated with QEMU command line > args, and initialize things like the map-cache for > 4GB guest support. > map-cache is one of those things I don't expect to ever get merged. > In the Xennite work I had further stuff going on there too - more general > initialization of Xenstore parameters - eg stuffing the name & uuid from > QEMU's argv into right place in xenstore. > Ideally, I'd like to see Xen/KVM integration look like this: 1) Xen support is detected in configure (libxc et al) and conditionally enabled. 2) When running on bare metal, detect whether KVM acceleration is available, also detect if kqemu acceleration is available 3) When running under Xen, detect that Xen is available, and create a full virt domain 4) If a user specifies a type=xen device, it should Just Work provided you are in a Xen environment (erroring appropriately) 5) A user can explicitly specify -M xenpv. If running under Xen, this would create a Xen PV guest. If running on bare metal, Xenner would be used to present a Xen shim layer. This should work with KVM acceleration or without KVM acceleration. Bonus points if it works with kqemu too. For 1-4, the user experience should not be different at all. This of course doesn't mean that users would be forced to interact directly with QEMU or that QEMU cannot be running within a stub domain. It would be good if these things could be automatically detected though. Regards, Anthony Liguori > Daniel >