From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40540) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmYXk-0003ZN-6I for qemu-devel@nongnu.org; Tue, 20 Sep 2016 23:49:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmYXf-0000BY-7u for qemu-devel@nongnu.org; Tue, 20 Sep 2016 23:49:55 -0400 Received: from ozlabs.org ([103.22.144.67]:51043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmYXe-0000Ar-Qc for qemu-devel@nongnu.org; Tue, 20 Sep 2016 23:49:51 -0400 Date: Wed, 21 Sep 2016 13:48:08 +1000 From: David Gibson Message-ID: <20160921034808.GW20488@umbus> References: <1473841548-26742-1-git-send-email-peterx@redhat.com> <1473841548-26742-2-git-send-email-peterx@redhat.com> <20160920061205.GV20488@umbus> <20160920071633.GD5134@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FlxqdQUIXA+HMkrt" Content-Disposition: inline In-Reply-To: <20160920071633.GD5134@pxdev.xzpeter.org> Subject: Re: [Qemu-devel] [PATCH v5 1/3] memory: introduce IOMMUNotifier and its caps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Xu Cc: qemu-devel@nongnu.org, mst@redhat.com, jasowang@redhat.com, vkaplans@redhat.com, alex.williamson@redhat.com, wexu@redhat.com, pbonzini@redhat.com, cornelia.huck@de.ibm.com, dgibson@redhat.com --FlxqdQUIXA+HMkrt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 20, 2016 at 03:16:33PM +0800, Peter Xu wrote: > On Tue, Sep 20, 2016 at 04:12:05PM +1000, David Gibson wrote: > > On Wed, Sep 14, 2016 at 04:25:46PM +0800, Peter Xu wrote: > > > IOMMU Notifier list is used for notifying IO address mapping changes. > > > Currently VFIO is the only user. > > >=20 > > > However it is possible that future consumer like vhost would like to > > > only listen to part of its notifications (e.g., cache invalidations). > > >=20 > > > This patch introduced IOMMUNotifier and IOMMUNotfierFlag bits for a > > > finer grained control of it. > > >=20 > > > IOMMUNotifier contains a bitfield for the notify consumer describing > > > what kind of notification it is interested in. Currently two kinds of > > > notifications are defined: > > >=20 > > > - IOMMU_NOTIFIER_MAP: for newly mapped entries (additions) > > > - IOMMU_NOTIFIER_UNMAP: for entries to be removed (cache invalidates) > > >=20 > > > When registering the IOMMU notifier, we need to specify one or multip= le > > > types of messages to listen to. > > >=20 > > > When notifications are triggered, its type will be checked against the > > > notifier's type bits, and only notifiers with registered bits will be > > > notified. > > >=20 > > > Signed-off-by: Peter Xu > >=20 > > I still don't see the big fat comment saying that in-place changes to > > an IOMMU mapping aren't permitted. >=20 > IMHO if we are using MAP and UNMAP here then it's fairly clear even we > will support in-place change in the future. I can add one more > paragraph for in-place change like: >=20 > For any IOMMU implementation, an in-place mapping change should be > notified with an UNMAP following a MAP. >=20 > Do you think this works? I guess it will do. >=20 > [...] >=20 > > > +struct IOMMUNotifier { > > > + void (*notify)(struct IOMMUNotifier *notifier, void *data); > >=20 > > Given that we now have a special notifier type for this purpose, we > > could actually type this to take an IOMMUTLBEntry instead of a void *. >=20 > Yep. I can fix that. Great. --=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 --FlxqdQUIXA+HMkrt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX4gL1AAoJEGw4ysog2bOS1IoQAL62SUBf4J55YJJPzhXsszei kXqz8NC6cZRf7b10/17hLfzhkG4den0QEyDv1PDgp+vhpg3ms2aPUI4ROcfxumsO cZ33WBu2yNjXR8YlcIu6x0hSBQRGqowbhrTVPa27kQ+1iEvykiQuHpzCnq4w1yWh A4jQfKlBf8iZEecnmzX2RSJeMMY43PgUeA7ZpxMgoc7mWpQ1D3MhRjWJIY5q8T/Y IM7Ol187Y4OAmRRYn87ft7Q+uAyCVOjzfD+W8crPZRHkrgJGaAy6hO8TTQ8PTimj tKwtIrKR5+pm8yQm/JHI+1pw03jsFMaua39Gib3cxrQltvzVOOMisGwtiChCAJLl yTNEfaxxsWrQ+FfelCAnMfCLsltUBNTbGf3b9N/t0nDXilP9xcobI543DomZgW1Y /PPYXTiIesYy6WFyuKvHEPoc26pws4N13RTqSR3RXHkBzR6UDaufl4P0SeDn7xGg qiRSeZwkphEewS4j8sehV76tmRmBMkgxt2f4j6ZWkRRh5UQxpXZgvK3ptUPVAc0X jgVXN1cR21y2/ffnaQPxsuDvgVHWr+VqoCXmQQ+tJyPRGHffoQCPe6kI4rHbwly4 +A5Q7MEu4an/zeaVE2x3m/cK49OA8Gg69AiUcc4XrcBTo37LvdKXdJ3sk1nGxoRj rGYSwf7XVu6VSqB3pVF7 =+P4k -----END PGP SIGNATURE----- --FlxqdQUIXA+HMkrt--