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

[Avi Kivity <avi@redhat.com>]

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.

-- 
error compiling committee.c: too many arguments to function