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

[Stefan Hajnoczi <stefanha@gmail.com>]

On Fri, Dec 17, 2010 at 4:19 PM, Yoshiaki Tamura
<tamura.yoshiaki@lab.ntt.co.jp> wrote:
> 2010/12/17 Stefan Hajnoczi <stefanha@gmail.com>:
>> On Thu, Dec 16, 2010 at 9:50 AM, Yoshiaki Tamura
>> <tamura.yoshiaki@lab.ntt.co.jp> wrote:
>>> 2010/12/16 Michael S. Tsirkin <mst@redhat.com>:
>>>> On Thu, Dec 16, 2010 at 04:37:41PM +0900, Yoshiaki Tamura wrote:
>>>>> 2010/11/28 Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>:
>>>>> > 2010/11/28 Michael S. Tsirkin <mst@redhat.com>:
>>>>> >> 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 <tamura.yoshiaki@lab.ntt.co.jp>
>>>>> >>
>>>>> >> 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/qemu-devel@nongnu.org/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.

I'm not sure I understand the question but I have considered making
ioeventfd a first-class interface like register_ioport_write().  In
some ways that would be cleaner than the way we use ioeventfd in vhost
and virtio-pci today.

>> 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.

If you add some functionality to vhost it might be possible, although
that would slow it down.  So perhaps for the near future using vhost
with Kemari is pointless anyway since you won't be able to reach the
performance that vhost-net can achieve.

Stefan