On Sun, Nov 14, 2010 at 10:34 AM, Avi Kivity <avi@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
