From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45681 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDICs-0004ZW-A6 for qemu-devel@nongnu.org; Tue, 02 Nov 2010 10:51:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDHM9-0006FF-Q4 for qemu-devel@nongnu.org; Tue, 02 Nov 2010 09:56:58 -0400 Received: from smtp.eu.citrix.com ([62.200.22.115]:60557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDHM9-0006Ey-Fm for qemu-devel@nongnu.org; Tue, 02 Nov 2010 09:56:57 -0400 Date: Tue, 2 Nov 2010 13:55:43 +0000 From: Stefano Stabellini Subject: Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn In-Reply-To: <4CCFE2AB.1050204@redhat.com> 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: Paolo Bonzini Cc: qemu-devel@gnu.org, Stefano Stabellini , Developers , Alexander Graf , Gerd Hoffmann On Tue, 2 Nov 2010, Paolo Bonzini wrote: > The question is, how much do the Xen userspace and Xenner have in common? > > If you remove code that Xen runs in the hypervisor or in the dom0 > kernel, or code that (like xenconsoled) is IMHO best moved to the Xenner > kernel, what remains is the domain builder and of course xenstore > handling. The domain builder is in libxc, which makes it hard to share, > and this leaves xenstore. > There is a xen console backend in qemu already (xen_console.c). > Now, half of it (the ring buffer protocol) already has a million > duplicate implementation in userspace, in the kernel, in Windows PV > drivers (at least three independent versions), and is pretty much set in > stone. > > So, what remains is actually parsing the xenstore messages and handling > the tree data structure. Which is actually a _very_ small part of > xenstored: xenstored has to work across multiple domains and clients, be > careful about inter-domain security, and so on. Xenner has the _big_ > advantage of having total independence between domUs (it's like if each > domU had its own little dom0, its own little xenstore and so on). While > it doesn't mean there are no security concerns with guest-facing code, > it simplifies the code to the point where effectively it makes no sense > to share anything but the APIs. > All right, if you feel that it would be easier for you to use your own simplified version, I am OK with that. However it is important that the mini-libxc, the mini-xenstored and the qemu domain builder are disable when using xen as accelerator. As I said before, running pure PV guests in a xen HVM domain should be one of the targets of the series, and in that case we do want to use the full featured xenstored and libxc and the libxenlight domain buider.