From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THBeN-0006BR-Kq for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:49:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THBeM-0006zi-Nd for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:48:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THBeM-0006zT-FL for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:48:58 -0400 Message-ID: <50642F12.2040504@redhat.com> Date: Thu, 27 Sep 2012 12:48:50 +0200 From: Avi Kivity MIME-Version: 1.0 References: <50597D1F.3070607@redhat.com> <505991A2.6090709@siemens.com> <5059954A.50408@redhat.com> <50600F7B.5080106@redhat.com> <50602B0A.1020403@redhat.com> <50641976.3020405@redhat.com> <50641C5F.2030202@redhat.com> <50641DB8.9090903@redhat.com> <50641E08.4040602@redhat.com> <506425B8.1040706@redhat.com> <506428F1.6090004@redhat.com> In-Reply-To: <506428F1.6090004@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [big lock] Discussion about the convention of device's DMA each other after breaking down biglock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Jan Kiszka , Marcelo Tosatti , liu ping fan , Anthony Liguori , "qemu-devel@nongnu.org" On 09/27/2012 12:22 PM, Paolo Bonzini wrote: > Il 27/09/2012 12:08, Avi Kivity ha scritto: >>>>>> virtio-net is per-spec not going through the iommu. >>>> >> What's that smell? A feature bit? >>> > >>> > Why is it a bad thing that it does not go through the iommu? >> You can't assign the device to nested guests or to guest userspace via >> vfio. Some guests may want to use the iommu even in the guest kernel >> context. > > All good points. > > However, using the iommu means you cannot use either vhost-net or (at > least for now) per-device lock. So it closes some doors on performance > improvements... I can imagine pSeries guys prefer to keep no iommu in > virtio devices. Eventually we'll have a kernel-emulated iommu for these use cases. We can use the shadow code to generate the gvioaddr -> gpa -> hpa translation (like we use shadow code to fold the ngpa -> gpa -> hpa translation into a single ngpa -> hpa translation with nested npt). -- error compiling committee.c: too many arguments to function