From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk2yh-0004HE-Hm for qemu-devel@nongnu.org; Wed, 14 Sep 2016 01:43:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bk2yd-00081D-D9 for qemu-devel@nongnu.org; Wed, 14 Sep 2016 01:43:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk2yd-00080v-7p for qemu-devel@nongnu.org; Wed, 14 Sep 2016 01:43:19 -0400 Date: Wed, 14 Sep 2016 13:43:12 +0800 From: Peter Xu Message-ID: <20160914054312.GL3776@pxdev.xzpeter.org> References: <20160906081737.GE21051@pxdev.xzpeter.org> <8a6c53f9-e3c4-f788-e794-30f28c184418@redhat.com> <20160906103142.GG21051@pxdev.xzpeter.org> <20160907054419.GN2780@voom.fritz.box> <20160907063419.GI21051@pxdev.xzpeter.org> <20160907064154.GR2780@voom.fritz.box> <20160908090732.GB28348@pxdev.xzpeter.org> <20160912012603.GD12621@voom.fritz.box> <20160912051341.GB3776@pxdev.xzpeter.org> <20160914040029.GH15077@voom.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160914040029.GH15077@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 Wed, Sep 14, 2016 at 02:00:29PM +1000, David Gibson wrote: [...] > > > > > > > > > > > So > > > > > > IIUC this is a question about "naming" but not the implementations... > > > > > > I suppose it is really a matter of taste, and both work for me (either > > > > > > INVALIDATION/CHANGE or UNMAP/MAP). > > > > > > > > > > No.. it is a question of implementation. My point is that I don't > > > > > think the new permission is sufficient information to let you know if > > > > > a notification is necessary. You need to know if there was an > > > > > existing mapping at that IOBA. > > > > > > > > My understanding is that we don't need to know that. Because IIUC > > > > there are only map_page() and unmap_page() in guest IOMMU driver > > > > (please check dma_map_ops in kernel). There is no chance for anyone to > > > > "change" the content of the mapping, unless it calls unmap_page() then > > > > with a map_page(). In that case, we'll have two IOTLB invalidation > > > > requests. > > > > > > That's assuming a Linux guest using the current guest IOMMU model. > > > > > > I don't think we do so in practice, but the PAPR hypercall interface > > > allows in-place changing of a mapping. The interface is just "set > > > this IOPTE to this value". > > > > I see. Even if so, QEMU IOMMU emulation codes can convert one CHANGE > > request into UNMAP and a continuous MAP, right? > > Yes, I guess so. Why is that preferable to issuing a single > notification to both "map" and "unmap" listeners though? So I think we should be talking about the same thing here (please correct me if I am wrong...). Please review v4 of this series and see whether that works (I renamed CHANGE into MAP, so there will be MAP/UNMAP, and I think things are clearer with it). Thanks! -- peterx