From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53616 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PCwvF-00088h-GJ for qemu-devel@nongnu.org; Mon, 01 Nov 2010 12:07:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCwv2-0005Wl-W6 for qemu-devel@nongnu.org; Mon, 01 Nov 2010 12:07:41 -0400 Received: from cantor.suse.de ([195.135.220.2]:34383 helo=mx1.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PCwv2-0005Vt-Na for qemu-devel@nongnu.org; Mon, 01 Nov 2010 12:07:36 -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: <4CCEE463.3090406@codemonkey.ws> Date: Mon, 1 Nov 2010 12:07:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8430EFFE-FE89-4B79-8FB5-4678E1F02C3F@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> 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:01, Anthony Liguori wrote: > On 11/01/2010 10:49 AM, Alexander Graf wrote: >> On 01.11.2010, at 11:45, Anthony Liguori wrote: >>=20 >> =20 >>> On 11/01/2010 10:01 AM, Alexander Graf wrote: >>> =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 >>> 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. I agree about the discussion part, that's why we're all gathering in = Boston this week, right? 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. Alex