From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40591 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PD8Zo-0006O1-9o for qemu-devel@nongnu.org; Tue, 02 Nov 2010 00:34:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PD8Zm-0004to-Kp for qemu-devel@nongnu.org; Tue, 02 Nov 2010 00:34:28 -0400 Received: from smtp.eu.citrix.com ([62.200.22.115]:58087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PD8Zm-0004tM-Fl for qemu-devel@nongnu.org; Tue, 02 Nov 2010 00:34:26 -0400 Date: Tue, 2 Nov 2010 04:33:12 +0000 From: Stefano Stabellini Subject: Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn In-Reply-To: <4CCF23E9.8070404@codemonkey.ws> 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> 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: Anthony Liguori Cc: Paolo Bonzini , Gerd Hoffmann , Alexander Graf , qemu-devel Developers On Mon, 1 Nov 2010, Anthony Liguori wrote: > On 11/01/2010 02:47 PM, Alexander Graf wrote: > > Where else would it belong? Qemu is an emulator. Device emulation belongs to qemu code. The xen PV machine is nothing but a special case of the pc machine with custom firmware and odd devices :). > > > > As I stated in my cover letter, the goal of all this should be to have the qemu pieces be 100% independent of any xen headers or libraries, > > I'm not sure I agree with the goal. I think where ever possible we > should reuse code with the Xen project when it makes sense. Reusing > blkback/netback is impossible because we want userspace implementations > and the current implementations are in the kernel. blktap also doesn't > tie into the QEMU block layer and making it tie into the QEMU block > layer would probably result in more code than it saved. > > OTOH, xenstored and xenconsoled have very little direct dependence on > Xen. I'm not saying that we shouldn't make things Just Work in QEMU, so > if that means spawning xenconsoled/xenstored automagically from QEMU > with special options, that's perfectly fine. > > But to replicate the functionality of this code solely because of NIH > seems like a waste of effort. > I have been traveling so I haven't had a chance to carefully read the series yet, however these are my early observations: I don't mind xenner, of course I think the best way to run a PV guest is to use Xen, but Xenner can be useful in many ways. I would love to see an x86_32 PV guest run on PowerPC, or even in a Xen HVM domain! It would be very useful for testing too, it would shorten my dev & test cycle by quite a bit. I am a strong proponent of code sharing and reuse so I agree with Anthony on this: we should reuse Xen libraries and daemons as much as possible. If you need some patches to port xenstored and/or xenconsoled to PowerPC we would gladly accept them. That said, many Xen components are obviously tied to the Xen architecture, so it might not be easy to reuse them outside a Xen environment. For example: making xenstored work without Xen shouldn't be too difficult but porting libxc to KVM/QEMU I think would be harder. I am looking forward to talking with you in Boston, Stefano