From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhWWa-0000Zo-2B for qemu-devel@nongnu.org; Wed, 07 Sep 2016 02:39:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhWWX-00010p-Qc for qemu-devel@nongnu.org; Wed, 07 Sep 2016 02:39:55 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:58825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhWWW-00010N-TP for qemu-devel@nongnu.org; Wed, 07 Sep 2016 02:39:53 -0400 Date: Wed, 7 Sep 2016 16:41:54 +1000 From: David Gibson Message-ID: <20160907064154.GR2780@voom.fritz.box> References: <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> <20160907063419.GI21051@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="19HmC3QOnaNVzKTI" Content-Disposition: inline In-Reply-To: <20160907063419.GI21051@pxdev.xzpeter.org> 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: Peter Xu 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 --19HmC3QOnaNVzKTI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 07, 2016 at 02:34:19PM +0800, Peter Xu wrote: > 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... > >=20 > > Right.. this brings up a good point. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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 > >=20 > > 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). > >=20 > > A "change" - replacing one mapping with another should count as both a > > "map" and "unmap" event. >=20 > 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. I think caring about invalidated cache *is* caring about unmap. It doesn't matter whether the new mapping is something or nothing - if the old mapping is no longer valid, you need to invalidate the cache, yes? > 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. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --19HmC3QOnaNVzKTI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJXz7ayAAoJEGw4ysog2bOSWrAQAMOlnA837QzY5J5AN4I78zy1 Nz9WzDWwPcN8z11M/NPNdxVP7axYosxx/QT6JdLYZq+sNzjXBtU6NuwRbfbUjmjl iaW4QL8JEtuZSUIwSoVQ/dkTKl1TVEI7mHm5d2aoDSTBwtzRoPLK3HTMA3HZtBpi +sB9/vjZkCT21FLa0NUSH3ikxHSXvnu269EUw8egk6HlAjUrpuMnAc12lT8hQig1 f/id6p5w7momIW8/ulF91k6bGTw64vpvTVD8YyDllcp8UechmzQaXUjKzv9A/QWS +LH7WuNCFtn+1y8RSfEazu8im9SM3JFUJpj9LAn8ho0eqIko5YbuPrNIIpXksNBQ hnN584OEGIA7VSBCp+Cfb7ap8cP2c9CfmV6apaHHqOvhNqJXZaybwqk75sTv03Q2 51GdZ59uPu7jBxZxhlamfAQ6sv9rIwYai9LI8F3AbjUtwGdgvqWjL4l5I9JRKHP+ HvSix5sw0ZnyqNFYPH5g7jO032frZfrQSbpbuBut867YuooxvC3McgB+AIAMFeda AsY7Qqb2+yMYwFw+Bh+Jtus4xTHhJ6KshkBWuQyqQbCCGM0Moa3DjoOV6Ls5X75a yGwr0WqwVu5kwKgcn3g1ftOS8IkOnoYqbmn0S01zzE/U1G0MLsf6wmYWcPL8bAXt 3QGhomgrmajYbX7HUBQB =RC+L -----END PGP SIGNATURE----- --19HmC3QOnaNVzKTI--