From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfJ9Z-0004n1-5i for qemu-devel@nongnu.org; Wed, 31 Aug 2016 23:59:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfJ9T-0001i8-7f for qemu-devel@nongnu.org; Wed, 31 Aug 2016 23:59:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfJ9T-0001i2-27 for qemu-devel@nongnu.org; Wed, 31 Aug 2016 23:58:55 -0400 Date: Thu, 1 Sep 2016 11:58:48 +0800 From: Peter Xu Message-ID: <20160901035848.GC3558@pxdev.xzpeter.org> References: <1472526419-5900-1-git-send-email-jasowang@redhat.com> <1472526419-5900-11-git-send-email-jasowang@redhat.com> <20160829213702.536df0df@t450s.home> <76fb2f05-4f9c-3e91-d301-3e0a6d4cabaf@redhat.com> <20160901022929.GA3558@pxdev.xzpeter.org> <20160831204342.77fbe728@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160831204342.77fbe728@t450s.home> Subject: Re: [Qemu-devel] [PATCH for 2.8 10/11] Revert "intel_iommu: Throw hw_error on notify_started" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Jason Wang , mst@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, cornelia.huck@de.ibm.com, wexu@redhat.com, vkaplans@redhat.com, David Gibson On Wed, Aug 31, 2016 at 08:43:42PM -0600, Alex Williamson wrote: > > > >>This reverts commit 3cb3b1549f5401dc3a5e1d073e34063dc274136f. Vhost > > > >>device IOTLB API will get notified and send invalidation request to > > > >>vhost through this notifier. > > > >AFAICT this series does not address the original problem for which > > > >commit 3cb3b1549f54 was added. We've only addressed the very narrow > > > >use case of a device iotlb firing the iommu notifier therefore this > > > >change is a regression versus 2.7 since it allows invalid > > > >configurations with a physical iommu which will never receive the > > > >necessary notifies from intel-iommu emulation to work properly. Thanks, > > > > > > > >Alex > > > > > > Looking at vfio, it cares about map but vhost only cares about IOTLB > > > invalidation. Then I think we probably need another kind of notifier in this > > > case to avoid this. > > > > Shall we leverage IOMMUTLBEntry.perm == IOMMU_NONE as a sign for > > invalidation? If so, we can use the same IOTLB interface as before. > > IMHO these two interfaces are not conflicting? > > > > Alex, > > > > Do you mean we should still disallow user from passing through devices > > while Intel IOMMU enabled? If so, not sure whether patch below can > > solve the issue. > > > > It seems that we need a "name" for either IOMMU notifier > > provider/consumer, and we should not allow (provider==Intel && > > consumer==VFIO) happen. In the following case, I added a name for > > provider, and VFIO checks it. > > Absolutely not, intel-iommu emulation is simply incomplete, the IOMMU > notifier is never called for mappings. There's a whole aspect of > iommu notifiers that intel-iommu simply hasn't bothered to implement. > Don't punish vfio for actually making use of the interface as it was > intended to be used. AFAICT you're implementing the unmap/invalidation > half, without the actual mapping half of the interface. It's broken > and incompatible with any iommu notifiers that expect to see both > sides. Thanks, Yeah I think I got your point. Thanks for the explanation. Now I agree with Jason that we may need another notifier mechanism. -- peterx