From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgnOc-0006vk-1m for qemu-devel@nongnu.org; Mon, 05 Sep 2016 02:28:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgnOY-0006G2-RW for qemu-devel@nongnu.org; Mon, 05 Sep 2016 02:28:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgnOY-0006Fv-M2 for qemu-devel@nongnu.org; Mon, 05 Sep 2016 02:28:38 -0400 Date: Mon, 5 Sep 2016 14:28:32 +0800 From: Peter Xu Message-ID: <20160905062832.GA7761@pxdev.xzpeter.org> References: <20160831204342.77fbe728@t450s.home> <20160901035848.GC3558@pxdev.xzpeter.org> <20160902141504.05950823@voom.fritz.box> <20160902053733.GB10595@pxdev.xzpeter.org> <20160902161014.7e53530b@voom.fritz.box> <20160902061557.GB18496@pxdev.xzpeter.org> <20160902061847.GC18496@pxdev.xzpeter.org> <20160902170028.48a01768@voom.fritz.box> <20160902093100.GD18496@pxdev.xzpeter.org> <20160902091301.30662d7a@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160902091301.30662d7a@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: David Gibson , Jason Wang , mst@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, cornelia.huck@de.ibm.com, wexu@redhat.com, vkaplans@redhat.com On Fri, Sep 02, 2016 at 09:13:01AM -0600, Alex Williamson wrote: > Maybe memory_region_register_iommu_notifier() could take an > IOMMUAccessFlags argument (filter) that is passed to the notify_started > callback. If a notifier client only cares about IOMMU_NONE > (invalidations), intel-iommu could allow it, regardless of the CM > setting (though I'm dubious whether this is complete in the generic > case or really only for device iotlbs). If a client requires IOMMU_RW > then intel-iommu would currently bomb-out like it does now, or once > that gets fixed it would bomb if CM=0. Ideally intel-iommu would > be fully functional, but somehow it was allowed into the tree > with this massive gap in support for QEMU iommu interfaces. Thanks, Yes, this idea should solve the issue, and looks simple. This should be based on the assumption that we will have only one notify register for each IOMMU memory region. However I think that does suit our use cases (no mix use for the two types). Meanwhile, I think we can cache this "notifier type" (or IOMMUAccessFlags) inside that memory region, and we can further verify the type any time we want (e.g., we can skip the notification if the type is not matched). I'll try to post a patch based on your suggestion, and see whether we like it. Thanks! -- peterx