From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: [PATCH 2/3] virtio-pci: Use ioeventfd for virtqueue notify Date: Sun, 14 Nov 2010 12:34:01 +0200 Message-ID: <4CDFBB19.7010702@redhat.com> References: <1289483242-6069-1-git-send-email-stefanha@linux.vnet.ibm.com> <1289483242-6069-3-git-send-email-stefanha@linux.vnet.ibm.com> <20101111164518.GA28773@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , Stefan Hajnoczi , qemu-devel@nongnu.org, kvm@vger.kernel.org, "Michael S. Tsirkin" To: Stefan Hajnoczi Return-path: Received: from mx1.redhat.com ([209.132.183.28]:10460 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754909Ab0KNKei (ORCPT ); Sun, 14 Nov 2010 05:34:38 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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