qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 28/40] xenner: libxc emu: evtchn


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 28/40] xenner: libxc emu: evtchn
Date: Mon, 01 Nov 2010 11:14:04 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

On 11/01/2010 11:07 AM, Alexander Graf wrote:
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:


On 11/01/2010 10:01 AM, Alexander Graf wrote:

Xenner emulates parts of libxc, so we can not use the real xen infrastructure
when running xen pv guests without xen.

This patch adds support for event channel communication.

Signed-off-by: Alexander Graf<address@hidden>


Has anyone checked with the Xen folks about supporting this type of 
functionality in libxc directly?

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?

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.

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.

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?

Fair enough :-)

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.

Yeah, I guess I'd just like to see a more "polite" solution.

Regards,

Anthony Liguori

Alex





reply via email to

[Prev in Thread] Current Thread [Next in Thread]