[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 28/40] xenner: libxc emu: evtchn
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] [PATCH 28/40] xenner: libxc emu: evtchn |
Date: |
Mon, 1 Nov 2010 12:07:32 -0400 |
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?
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
- [Qemu-devel] [PATCH 04/40] elf: add section analyzer, (continued)
- [Qemu-devel] [PATCH 04/40] elf: add section analyzer, Alexander Graf, 2010/11/01
- [Qemu-devel] [PATCH 10/40] xenner: kernel: Hypercall handler (i386), Alexander Graf, 2010/11/01
- [Qemu-devel] [PATCH 11/40] xenner: kernel: Hypercall handler (x86_64), Alexander Graf, 2010/11/01
- [Qemu-devel] [PATCH 07/40] xenner: kernel: 32 bit files, Alexander Graf, 2010/11/01
- [Qemu-devel] [PATCH 26/40] xenner: kernel: xen-names, Alexander Graf, 2010/11/01
- [Qemu-devel] [PATCH 16/40] xenner: kernel: Main (i386), Alexander Graf, 2010/11/01
- [Qemu-devel] [PATCH 28/40] xenner: libxc emu: evtchn, Alexander Graf, 2010/11/01
- [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Paolo Bonzini, 2010/11/01
- [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Anthony Liguori, 2010/11/01
- [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Alexander Graf, 2010/11/01
- [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Anthony Liguori, 2010/11/01
- [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Paolo Bonzini, 2010/11/01
- [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Anthony Liguori, 2010/11/01
- [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Paolo Bonzini, 2010/11/01
- [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Anthony Liguori, 2010/11/01