From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhWRK-0007Ap-Um for qemu-devel@nongnu.org; Wed, 07 Sep 2016 02:34:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhWRG-00005M-M8 for qemu-devel@nongnu.org; Wed, 07 Sep 2016 02:34:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhWRG-000058-Gd for qemu-devel@nongnu.org; Wed, 07 Sep 2016 02:34:26 -0400 Date: Wed, 7 Sep 2016 14:34:19 +0800 From: Peter Xu Message-ID: <20160907063419.GI21051@pxdev.xzpeter.org> References: <1473060081-17835-3-git-send-email-peterx@redhat.com> <2112298c-fe2a-c74f-7a68-a92625cd3533@redhat.com> <20160905083804.GB7761@pxdev.xzpeter.org> <20160906052733.GA21051@pxdev.xzpeter.org> <92b5128b-d6e2-5787-9cea-07fcf90d22a5@redhat.com> <20160906081737.GE21051@pxdev.xzpeter.org> <8a6c53f9-e3c4-f788-e794-30f28c184418@redhat.com> <20160906103142.GG21051@pxdev.xzpeter.org> <20160907054419.GN2780@voom.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160907054419.GN2780@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 07, 2016 at 03:44:19PM +1000, David Gibson wrote: > > For "CHANGE", it sounds like a unmap() + a map(). However I'd say > > "ADDITION" is nowhere better... > > Right.. this brings up a good point. > > Changing a mapping (i.e. overwriting an existing mapping with a > different one) would also need notification, even on x86, no? Since > it implicitly invalidates the previous mapping. > > I'm guessing the guest will avoid this by always unmapping before it > maps. We still need to consider this possibility when designing the > notifier interface though. > > It seems the real notification triggers here are: > * map - something is mapped which previously wasn't > * unmap - something is no longer mapped which was before > > Note that whether the second needs to be triggered depends on the > *previous* state of that IOBA range, *not* on the permissions of the > new mapping (if any). > > A "change" - replacing one mapping with another should count as both a > "map" and "unmap" event. Yeah... For MAP/UNMAP, it is strange in another way: e.g. for vhost, it doesn't care about map/unmap, it cares about invalidated cache. 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). Thanks, -- peterx