From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51014 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PD2QN-00077B-7b for qemu-devel@nongnu.org; Mon, 01 Nov 2010 18:00:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PD2QM-0002dj-55 for qemu-devel@nongnu.org; Mon, 01 Nov 2010 18:00:19 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:64734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PD2QM-0002dZ-1D for qemu-devel@nongnu.org; Mon, 01 Nov 2010 18:00:18 -0400 Received: by gya6 with SMTP id 6so3923621gya.4 for ; Mon, 01 Nov 2010 15:00:17 -0700 (PDT) Message-ID: <4CCF386D.5020302@codemonkey.ws> Date: Mon, 01 Nov 2010 17:00:13 -0500 From: Anthony Liguori MIME-Version: 1.0 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> <4CCF357E.9010208@redhat.com> In-Reply-To: <4CCF357E.9010208@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Gerd Hoffmann , Alexander Graf , qemu-devel Developers On 11/01/2010 04:47 PM, Paolo Bonzini wrote: > On 11/01/2010 09:32 PM, Anthony Liguori wrote: >> >> 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. > > xenstored is 3 times bigger than what Alex submitted, however. The > code is much simpler because _this_ xenstore only serves one domain. > So it doesn't have to implement permissions, it doesn't have > complicated threading to handle multiple instances of libxs accessing > the daemon, and so on. Besides the data structures implementing the > tree, there's really very little in common, and the xenner code is > almost trivial. > > The situation is similar for the console. There is only one console > to track here. In fact, maybe it's simplest to implement it as a > small 8250A driver in the xenner kernel, reading from the serial > console at 0x3f8 and writing to the ring buffer and vice versa. Okay, so does the same apply for xenstored? Does it make more sense to move that into the xenner kernel? The big advantage of the xenner kernel is that it runs in guest mode so it's no concern from a security PoV. While xenstored is 3x bigger than Alex's version, it also has had an awful lot more validation from a security point of view. Since this is guest facing code, that's important. Regards, Anthony Liguori > > Paolo