From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5kRd-0001IY-DP for qemu-devel@nongnu.org; Wed, 25 May 2016 21:50:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5kRT-00053h-7n for qemu-devel@nongnu.org; Wed, 25 May 2016 21:50:40 -0400 Date: Thu, 26 May 2016 11:00:28 +1000 From: David Gibson Message-ID: <20160526010028.GT17226@voom.fritz.box> References: <1462344751-28281-1-git-send-email-aik@ozlabs.ru> <1462344751-28281-2-git-send-email-aik@ozlabs.ru> <20160505163941.7628431c@t450s.home> <0f2ca845-0c9a-5446-ea69-371ea866319e@ozlabs.ru> <20160513162453.0d367e95@t450s.home> <20160525063437.GN17226@voom.fritz.box> <20160525075926.13b24bf3@ul30vt.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lzfPtAjrR1KYNfg0" Content-Disposition: inline In-Reply-To: <20160525075926.13b24bf3@ul30vt.home> Subject: Re: [Qemu-devel] [PATCH qemu v16 01/19] vfio: Delay DMA address space listener release List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Alexey Kardashevskiy , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Alexander Graf , Paolo Bonzini --lzfPtAjrR1KYNfg0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 25, 2016 at 07:59:26AM -0600, Alex Williamson wrote: > On Wed, 25 May 2016 16:34:37 +1000 > David Gibson wrote: >=20 > > On Fri, May 13, 2016 at 04:24:53PM -0600, Alex Williamson wrote: > > > On Fri, 13 May 2016 17:16:48 +1000 > > > Alexey Kardashevskiy wrote: > > > =20 > > > > On 05/06/2016 08:39 AM, Alex Williamson wrote: =20 > > > > > On Wed, 4 May 2016 16:52:13 +1000 > > > > > Alexey Kardashevskiy wrote: > > > > > =20 > > > > >> This postpones VFIO container deinitialization to let region_del= () > > > > >> callbacks (called via vfio_listener_release) do proper clean up > > > > >> while the group is still attached to the container. =20 > > > > > > > > > > Any mappings within the container should clean themselves up when= the > > > > > container is deprivleged by removing the last group in the kernel= =2E Is > > > > > the issue that that doesn't happen, which would be a spapr vfio k= ernel > > > > > bug, or that our QEMU side structures get all out of whack if we = let > > > > > that happen? =20 > > > >=20 > > > > My mailbase got corrupted, missed that. > > > >=20 > > > > This is mostly for "[PATCH qemu v16 17/19] spapr_iommu, vfio, memor= y:=20 > > > > Notify IOMMU about starting/stopping being used by VFIO", I should = have put=20 > > > > 01/19 and 02/19 right before 17/19, sorry about that. =20 > > >=20 > > > Which I object to, it's just ridiculous to have vfio start/stop > > > callbacks in a set of generic iommu region ops. =20 > >=20 > > It's ugly, but I don't actually see a better way to do this (the > > general concept of having vfio start/stop callbacks, that is, not the > > specifics of the patches). > >=20 > > The fact is that how we implement the guest side IOMMU *does* need to > > change depending on whether VFIO devices are present or not.=20 >=20 > No, how the guest side iommu is implemented needs to change depending > on whether there's someone, anyone, in QEMU that cares about the iommu, > which can be determined by whether the iommu notifier has any clients. > Alexey has posted another patch that does this. *thinks* ah, yes, you're right of course. So instead we need some hook that's triggered on transition of number of notifier listeners =66rom zero<->non-zero. > > That's > > due essentially to incompatibilities between a couple of kernel > > mechanisms. Which in itself is ugly, but nonetheless real. > >=20 > > A (usually blank) vfio on/off callback in the guest side IOMMU ops > > seems like the least-bad way to handle this. >=20 > I disagree, we already call memory_region_register_iommu_notifier() to > indicate we care about the guest iommu, so the abstraction is already > there, there's absolutely no reason to make a vfio specific interface. > Thanks, >=20 > Alex >=20 --=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 --lzfPtAjrR1KYNfg0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXRkqsAAoJEGw4ysog2bOSTzUQALfPK4IMd3IoO1UVFfhgfczV Mm1mN7zjRhhThZULpgwNyfyKg6ablIt0Y8yLULhPcvHoxlvaf09WClatdJ100sm7 2i3ydFGwLzyL4MNXH0kA2GaWAObK9KJuhLZL7S/kiP7xbfEczaN9hs+/07z4CTgh I/G2VVr3VYmc1P+uSv/61cnvHxK9DHPEhvi178csMS+xVIW0HTJR7kvPlBwjIdhj puqhaEWmuomglramOZltDhKVSL8tvRJbYPdiigt99MgnRKPSiWUNS5p+E1rzNdP7 E1X16IxMzEBFDydaFzi+3++F/79DYraKDlxMRwomgoAz2HkdA/kLq19QjhAdQy3I 5WClBNNtnU04UZzprW3hl9OZdSngv0nEsHXb7YxT0/7ABhHOU1GfEfwl6MJq/LRQ L/mXTlbCWb5HptZ7VWxyb3+HWVlUatXuoGzm9nUT6BlJnxOHW4wC8HH5WxT5YgOO LEOGBx7nSpk8+jh4D5t5eEx4A0GWqAD6alYX0gpcGUPM8ZWHNmrjL4aEaNLOaaBA XvSvjmDgwi0Dw52JvyyGnvcgZBEGFyVWinT4cewHpEk4SMWWVNHxSvpMcPSefHfm ZA8wTEGyIo60FCwmPiatI+nt53H9jveOGH4zydoiETynEAsmPs1b35RFf2IBSr0d wA40+8KcgWsMvoYc9g7E =4w27 -----END PGP SIGNATURE----- --lzfPtAjrR1KYNfg0--