On Thu, Nov 11, 2010 at 4:45 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Thu, Nov 11, 2010 at 01:47:21PM +0000, Stefan Hajnoczi wrote: >> Some virtio devices are known to have guest drivers which expect a notify to be >> processed synchronously and spin waiting for completion. Only enable ioeventfd >> for virtio-blk and virtio-net for now. > > 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. 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. 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
