From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55239 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDMQd-0001gE-KC for qemu-devel@nongnu.org; Tue, 02 Nov 2010 15:22:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDMQJ-0000GT-LR for qemu-devel@nongnu.org; Tue, 02 Nov 2010 15:21:36 -0400 Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:19877 helo=SMTP.EU.CITRIX.COM) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDMQJ-0000Es-FT for qemu-devel@nongnu.org; Tue, 02 Nov 2010 15:21:35 -0400 Date: Tue, 2 Nov 2010 19:20:19 +0000 From: Stefano Stabellini Subject: Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn In-Reply-To: Message-ID: References: <1288623713-28062-1-git-send-email-agraf@suse.de> <1288623713-28062-29-git-send-email-agraf@suse.de> <4CCEE08F.4030403@codemonkey.ws> <4CCEE463.3090406@codemonkey.ws> <4CCF176F.2020600@redhat.com> <4CCF17EF.8090502@codemonkey.ws> <0A26E838-7FF5-4E4C-98EB-5EB0821460B9@suse.de> <4CCF23E9.8070404@codemonkey.ws> <4CCFE2AB.1050204@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Paolo Bonzini , Gerd Hoffmann , qemu-devel Developers , Stefano Stabellini On Tue, 2 Nov 2010, Alexander Graf wrote: > This is getting confusing :). There are multiple ways of spawning a Xen PV instance I'm aware of: > > 1) Xen PV context > 2) Xen PV context in SVM/VMX container, maintained by Xen > 3) Xenner on TCG/KVM > 4) Xenner on Xen HVM > > For 1 and 2 the way to go is definitely to reuse the xen infrastructure. For 3 I'm very reluctant in requiring dependencies. One of qemu's strong points is that it does not have too many dependencies on other code. If there are strong points for it however, I gladly change my position :). > > For 4 however, I haven't fully made up my mind on if it's useful to people (if you say it is, I'm more than glad to get this rolling!) and what the best way to implement it would be. > I am guessing that with 2) you are referring to Linux PV on HVM guests. If so 2) and 4) are very different: a Linux PV on HVM guest is a normal Linux kernel that would boot just fine on native, but is also able to enable some Xen PV interfaces when running in a Xen HVM domain. Linux PV on HVM guests are new and support is in the kernel since less than a year. However Linux PV guests have been around for a long time and traditionally are unable to boot on native or in a Xen HVM container. So 4) would allow these kernels to boot in a Xen HVM container unmodified, this is why it would be useful. > So I suppose your suggestion is to use the xen infrastructure for case 4? That might work out. Fortunately, all the detection on which backend we use happens at runtime. Since in that case Xen does own the guest's memory, we might even be safe on using its memory mapping functionality. Maybe. > Yes. Case 4) is just a normal Xen HVM domain from the Xen point of view, so it needs all the rest of the Xen infrastructure. There is no need to replace xenstored or libxc when the real xenstored and libxc are available. > I'm looking very much forward to talking to you about this in Boston. Are you around already? > Yep!