qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 11/21] ioport: insert event_tap_ioport() to iopo


From: Yoshiaki Tamura
Subject: [Qemu-devel] Re: [PATCH 11/21] ioport: insert event_tap_ioport() to ioport_write().
Date: Sat, 18 Dec 2010 01:19:14 +0900

2010/12/17 Stefan Hajnoczi <address@hidden>:
> On Thu, Dec 16, 2010 at 9:50 AM, Yoshiaki Tamura
> <address@hidden> wrote:
>> 2010/12/16 Michael S. Tsirkin <address@hidden>:
>>> On Thu, Dec 16, 2010 at 04:37:41PM +0900, Yoshiaki Tamura wrote:
>>>> 2010/11/28 Yoshiaki Tamura <address@hidden>:
>>>> > 2010/11/28 Michael S. Tsirkin <address@hidden>:
>>>> >> On Thu, Nov 25, 2010 at 03:06:50PM +0900, Yoshiaki Tamura wrote:
>>>> >>> Record ioport event to replay it upon failover.
>>>> >>>
>>>> >>> Signed-off-by: Yoshiaki Tamura <address@hidden>
>>>> >>
>>>> >> Interesting. This will have to be extended to support ioeventfd.
>>>> >> Since each eventfd is really just a binary trigger
>>>> >> it should be enough to read out the fd state.
>>>> >
>>>> > Haven't thought about eventfd yet.  Will try doing it in the next
>>>> > spin.
>>>>
>>>> Hi Michael,
>>>>
>>>> I looked into eventfd and realized it's only used with vhost now.
>>>
>>> There are patches on list to use it for block/userspace net.
>>
>> Thanks.  Now I understand.
>> In that case, inserting an even-tap function to the following code
>> should be appropriate?
>>
>> int event_notifier_test_and_clear(EventNotifier *e)
>> {
>>    uint64_t value;
>>    int r = read(e->fd, &value, sizeof(value));
>>    return r == sizeof(value);
>> }
>>
>>>
>>>>  However, I
>>>> believe vhost bypass the net layer in qemu, and there is no way for Kemari 
>>>> to
>>>> detect the outputs.  To me, it doesn't make sense to extend this patch to
>>>> support eventfd...
>
> Here is the userspace ioeventfd patch series:
> http://www.mail-archive.com/address@hidden/msg49208.html
>
> Instead of switching to QEMU userspace to handle the virtqueue kick
> pio write, we signal the eventfd inside the kernel and resume guest
> code execution.  The I/O thread can then process the virtqueue kick in
> parallel to guest code execution.
>
> I think this can still be tied into Kemari.  If you are switching to a
> pure net/block-layer event tap instead of pio/mmio, then I think it
> should just work.

That should take a while until we solve how to set correct
callbacks to the secondary upon failover.  BTW, do you have a
plan to move the eventfd framework to the upper layer as
pio/mmio.  Not only Kemari works for free, other emulators should
be able to benefit from it.

> For vhost it would be more difficult to integrate with Kemari.

At this point, it's impossible.  As Michael said, I should
prevent starting Kemari when vhost=on.

Yoshi

>
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



reply via email to

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