From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh9Lr-00028v-6R for qemu-devel@nongnu.org; Tue, 06 Sep 2016 01:55:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bh9Lm-0005sW-6C for qemu-devel@nongnu.org; Tue, 06 Sep 2016 01:55:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh9Lm-0005sS-0n for qemu-devel@nongnu.org; Tue, 06 Sep 2016 01:55:14 -0400 Date: Tue, 6 Sep 2016 13:55:08 +0800 From: Peter Xu Message-ID: <20160906055508.GD21051@pxdev.xzpeter.org> References: <1473060081-17835-1-git-send-email-peterx@redhat.com> <1473060081-17835-3-git-send-email-peterx@redhat.com> <2112298c-fe2a-c74f-7a68-a92625cd3533@redhat.com> <20160905083804.GB7761@pxdev.xzpeter.org> <20160906051846.GD16479@voom.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160906051846.GD16479@voom.fritz.box> Subject: Re: [Qemu-devel] [PATCH 2/3] memory: add iommu_notify_flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Paolo Bonzini , mst@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, cornelia.huck@de.ibm.com, alex.williamson@redhat.com, wexu@redhat.com, vkaplans@redhat.com, dgibson@redhat.com On Tue, Sep 06, 2016 at 03:18:46PM +1000, David Gibson wrote: > > Maybe here naming the flags as IOMMU_{RW_NONE} is a little bit > > confusing (just to leverage existing access flags), but what I was > > trying to do is to make the two things not overlapped at all, since I > > didn't find a mixture use case. > > Maybe not now, but a common use case is absolutely possible. If you > had a single (guest) bus with a single IO address space, with vIOMMU > and both VFIO and vhost devices on it, the same vIOMMU would need to > send all notifications to VFIO and (at least) unmap notifications to > vhost. Yeah this is a good one... Thanks to point out. Then I agree that splitting the use cases won't be enough... We may need to exactly register IOMMU notifiers with notification type (invalidations only, or we also need entry additions), and we just selectively notify the consumers depending on what kind of notification it is. Or any smarter way to do it. -- peterx