From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60893 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PCx3M-0003k6-Km for qemu-devel@nongnu.org; Mon, 01 Nov 2010 12:16:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCx2u-0007UU-Mh for qemu-devel@nongnu.org; Mon, 01 Nov 2010 12:15:49 -0400 Received: from cantor.suse.de ([195.135.220.2]:34548 helo=mx1.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PCx2u-0007UF-8W for qemu-devel@nongnu.org; Mon, 01 Nov 2010 12:15:44 -0400 Subject: Re: [Qemu-devel] [PATCH 28/40] xenner: libxc emu: evtchn Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: <4CCEE74C.6090209@codemonkey.ws> Date: Mon, 1 Nov 2010 12:15:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F632DC1-7EF6-4101-A306-ADC526E94969@suse.de> 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> <8430EFFE-FE89-4B79-8FB5-4678E1F02C3F@suse.de> <4CCEE74C.6090209@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel Developers , Gerd Hoffmann On 01.11.2010, at 12:14, Anthony Liguori wrote: > On 11/01/2010 11:07 AM, Alexander Graf wrote: >> On 01.11.2010, at 12:01, Anthony Liguori wrote: >>=20 >> =20 >>> On 11/01/2010 10:49 AM, Alexander Graf wrote: >>> =20 >>>> On 01.11.2010, at 11:45, Anthony Liguori wrote: >>>>=20 >>>>=20 >>>> =20 >>>>> On 11/01/2010 10:01 AM, Alexander Graf wrote: >>>>>=20 >>>>> =20 >>>>>> Xenner emulates parts of libxc, so we can not use the real xen = infrastructure >>>>>> when running xen pv guests without xen. >>>>>>=20 >>>>>> This patch adds support for event channel communication. >>>>>>=20 >>>>>> Signed-off-by: Alexander Graf >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>> Has anyone checked with the Xen folks about supporting this type = of functionality in libxc directly? >>>>>=20 >>>>> =20 >>>> The issue I have with libxc is that it goes orthogonal to the qemu = infrastructure way of doing things. If we base on libxc, we will never = be able to do cross-architecture execution of xen pv guests. Do we = really want to go that way? >>>>=20 >>>> =20 >>> IIUC, this is a mini-libxc that you enable by mucking with = LD_LIBRARY_PATH such that you can run things like xenstored unmodified. = What I'm really asking is whether there has been a discussion about a = more pleasant way to do this that the Xen guys would feel comfortable = with. >>>=20 >>> I'd feel a little weird if someone was replacing a part of QEMU via = LD_LIBRARY_PATH trickery. It's better to try to work out a proper = solution with the upstream community than to do trickery. >>>=20 >>> I'm not entirely opposed to this if the Xen guys say they don't want = anything to do with Xenner, but we should have the discussion at least. >>> =20 >> I agree about the discussion part, that's why we're all gathering in = Boston this week, right? >> =20 >=20 > Fair enough :-) >=20 >> But technically, this code really just bumps all libxc calls to = indirect function calls that go through a struct. If we're using xenner, = we use our own implementation, if we're using xen, we use xen's. The = thing is that with xenner we usually don't have xen infrastructure = available and most likely don't want to start any either. >> =20 >=20 > Yeah, I guess I'd just like to see a more "polite" solution. We can try and see if we can maybe reuse parts of the event channel and = xenstored stuff, but when it comes to memory mappings or grant tables, = we have to have our own code since we're the ones owning the ram. But yeah, let's move that discussion to LPC :). That way the xen folks = can participate! Alex