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

Avi Kivity
2010-11-14T10:34:38Z

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