On Sun, Nov 14, 2010 at 10:34 AM, Avi Kivity<address@hidden> 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.