Re: [Qemu-devel] Re: [PATCH 2/3] virtio-pci: Use ioeventfd for virtqueue notify

[Stefan Hajnoczi <stefanha@gmail.com>]

On Sun, Nov 14, 2010 at 10:34 AM, Avi Kivity <avi@redhat.com> wrote:
> On 11/12/2010 11:20 AM, Stefan Hajnoczi wrote:
>>
>> >  Who guarantees that less common virtio-blk and virtio-net guest drivers
>> >  for non-Linux OSes are fine with it?  Maybe you should add a feature
>> > flag
>> >  that the guest has to ACK to enable it.
>>
>> Virtio-blk and virtio-net are fine.  Both of those devices are
>> expected to operate asynchronously.  SeaBIOS and gPXE virtio-net
>> drivers spin but they expect to and it is okay in those environments.
>> They already burn CPU today.
>>
>> Virtio-console expects synchronous virtqueue kick.  In Linux,
>> virtio_console.c __send_control_msg() and send_buf() will spin.  Qemu
>> userspace is able to complete those requests synchronously so that the
>> guest never actually burns CPU (e.g.
>> hw/virtio-serial-bus.c:send_control_msg()).  I don't want to burn CPU
>> in places where we previously didn't.
>
> This is a horrible bug.  virtio is an asynchronous API.  Some hypervisor
> implementations cannot even provide synchronous notifications.
>
>> It's good that QEMU can decide whether or not to handle virtqueue kick
>> in the vcpu thread.  For high performance asynchronous devices like
>> virtio-net and virtio-blk it makes sense to use ioeventfd.  For others
>> it may not be useful.  I'm not sure a feature bit that exposes this
>> detail to the guest would be useful.
>
> The guest should always assume that virtio devices are asynchronous.

I agree, but let's enable virtio-ioeventfd carefully because bad code
is out there.

Stefan