From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk2S7-000697-Ju for qemu-devel@nongnu.org; Wed, 14 Sep 2016 01:09:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bk2S4-00056o-4v for qemu-devel@nongnu.org; Wed, 14 Sep 2016 01:09:42 -0400 Received: from ozlabs.org ([103.22.144.67]:39773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk2S3-00055i-EN for qemu-devel@nongnu.org; Wed, 14 Sep 2016 01:09:40 -0400 Date: Wed, 14 Sep 2016 14:00:29 +1000 From: David Gibson Message-ID: <20160914040029.GH15077@voom.fritz.box> References: <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> <20160907064154.GR2780@voom.fritz.box> <20160908090732.GB28348@pxdev.xzpeter.org> <20160912012603.GD12621@voom.fritz.box> <20160912051341.GB3776@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mhjHhnbe5PrRcwjY" Content-Disposition: inline In-Reply-To: <20160912051341.GB3776@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 --mhjHhnbe5PrRcwjY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 12, 2016 at 01:13:41PM +0800, Peter Xu wrote: > On Mon, Sep 12, 2016 at 11:26:04AM +1000, David Gibson wrote: > > On Thu, Sep 08, 2016 at 05:07:32PM +0800, Peter Xu wrote: > > > On Wed, Sep 07, 2016 at 04:41:54PM +1000, David Gibson wrote: > > > > 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 befo= re it > > > > > > maps. We still need to consider this possibility when designin= g 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 t= he > > > > > > *previous* state of that IOBA range, *not* on the permissions o= f 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 vho= st, > > > > > it doesn't care about map/unmap, it cares about invalidated cache. > > > >=20 > > > > 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 cach= e, > > > > yes? > > >=20 > > > Yes, I think these two are exactly the same in implementation (vhost > > > needs UNMAP events of course). So that's why I called it "a naming > > > issue". :) > > >=20 > > > >=20 > > > > > So > > > > > IIUC this is a question about "naming" but not the implementation= s... > > > > > I suppose it is really a matter of taste, and both work for me (e= ither > > > > > INVALIDATION/CHANGE or UNMAP/MAP). > > > >=20 > > > > 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 > > > 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. > >=20 > > That's assuming a Linux guest using the current guest IOMMU model. > >=20 > > 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". >=20 > 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? --=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 --mhjHhnbe5PrRcwjY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJX2MtdAAoJEGw4ysog2bOSfboQAL+YSKVtnrNU+jyzQL84+PO1 7jBSuuITci6an4jh8mbLMtdoENg2C4luoEcFsp7DJpvjkxnx3CgMrhRzT45WZuGV PAT9cBcF91Y5n48/qLcZeht/gca/gGtWC5al1yPlhLL3m5YioCX9s7m0w1z2SL4E LyI+ozQS2xrKpvr8jlbXyrmf9xJ1lRNN9YBhuF4IZF5oW1XJOyxasqdmH5L1LaTo HSjxURSAXilDTXsMIJX8ymQ1cFK7OrCc3y5pdj9fnVEwa3olGnlVr8nlfcviZynM 9WD8A8e63h1s8GHQUXUrKCPZv6jvoZd1cwsz0wQah3Zakh7PSWZpTmhnne6gPQOC HgoPaOrkXCRVAllT5ugbMNhAbhN0A9m+UnMhN3UCvyJLBrw1DFgntpHGE4zFoXVi Xc4bA9lu0I80XdLNyq1FDiTJO3kv6B+iVSaClT1auWAxHL7GGBxCzB0pRoDLk6Ul 7ohFLEqbhiainGnefKIfbmTzbbCgc52Eo0skW5aZbw9xPpRQVYYs7exQf1cTFCrv AntAW1+D005giLAu1goanqp4dWPD8QRgr1dtvf0cDQGB5S0N+4LSe5YK8lCv8Z6o 3OIHOcHgUlNHmJhm6tHJOEUjtsRDr+BgnWjnwECJuHDueCYi045UJm7dVdaaGk+e FmqbJJgm/5WUpEpeb4WX =otWq -----END PGP SIGNATURE----- --mhjHhnbe5PrRcwjY--