From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4tCt-0003KN-BP for qemu-devel@nongnu.org; Thu, 10 Nov 2016 12:32:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4tCo-0006UF-Ep for qemu-devel@nongnu.org; Thu, 10 Nov 2016 12:32:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47288) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c4tCo-0006Tl-9Y for qemu-devel@nongnu.org; Thu, 10 Nov 2016 12:32:06 -0500 Date: Thu, 10 Nov 2016 19:32:03 +0200 From: "Michael S. Tsirkin" Message-ID: <20161110192959-mutt-send-email-mst@kernel.org> References: <1478165243-4767-1-git-send-email-jasowang@redhat.com> <1478165243-4767-8-git-send-email-jasowang@redhat.com> <20161103214712-mutt-send-email-mst@kernel.org> <7157aba3-bd5d-c335-78a7-2f79ee576f8d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7157aba3-bd5d-c335-78a7-2f79ee576f8d@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V2 07/11] virtio-pci: address space translation service (ATS) support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: peterx@redhat.com, wexu@redhat.com, qemu-devel@nongnu.org, vkaplans@redhat.com, pbonzini@redhat.com, cornelia.huck@de.ibm.com On Fri, Nov 04, 2016 at 02:48:20PM +0800, Jason Wang wrote: >=20 >=20 > On 2016=E5=B9=B411=E6=9C=8804=E6=97=A5 03:49, Michael S. Tsirkin wrote: > > On Thu, Nov 03, 2016 at 05:27:19PM +0800, Jason Wang wrote: > > > >This patches enable the Address Translation Service support for vi= rtio > > > >pci devices. This is needed for a guest visible Device IOTLB > > > >implementation and will be required by vhost device IOTLB API > > > >implementation for intel IOMMU. > > > > > > > >Cc: Michael S. Tsirkin > > > >Signed-off-by: Jason Wang > > I'd like to understand why do you think this is strictly required. > > Won't setting CM bit in the IOMMU do the trick. >=20 > ATS was chosen for performance. Since there're many problems for CM: >=20 > - CM was slow (10%-20% slower on real hardware for things like netperf) > because of each transition between non-present and present mapping need= s an > explicit invalidation. It may slow down the whole VM. > - Without ATS/Device IOTLB, IOMMU becomes a bottleneck because of conte= nding > of IOTLB entries. (What we can do in this case is in fact userspace IOT= LB > snooping, this could be done even without CM). > It was natural to think of ATS when designing interface between IOMMU a= nd > device/remote IOTLBs. Do you see any drawbacks on ATS here? >=20 > Thanks In fact at this point I'm confused. Any mapping needs to be programmed in the IOMMU. We need to implement this correctly. Once we do why do we need ATS? I think what you need is map/unmap notifiers that Aviv is working on. No? > >=20 > > Also, could you remind me pls - can guests just disable ATS? > >=20 > > What happens then? > >=20 > >=20