From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh8pa-0006MO-B0 for qemu-devel@nongnu.org; Tue, 06 Sep 2016 01:21:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bh8pU-00008w-Ri for qemu-devel@nongnu.org; Tue, 06 Sep 2016 01:21:57 -0400 Received: from ozlabs.org ([103.22.144.67]:43683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh8pU-00007m-GB for qemu-devel@nongnu.org; Tue, 06 Sep 2016 01:21:52 -0400 Date: Tue, 6 Sep 2016 15:18:46 +1000 From: David Gibson Message-ID: <20160906051846.GD16479@voom.fritz.box> References: <1473060081-17835-1-git-send-email-peterx@redhat.com> <1473060081-17835-3-git-send-email-peterx@redhat.com> <2112298c-fe2a-c74f-7a68-a92625cd3533@redhat.com> <20160905083804.GB7761@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8w3uRX/HFJGApMzv" Content-Disposition: inline In-Reply-To: <20160905083804.GB7761@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 --8w3uRX/HFJGApMzv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 05, 2016 at 04:38:04PM +0800, Peter Xu wrote: > On Mon, Sep 05, 2016 at 10:04:42AM +0200, Paolo Bonzini wrote: > >=20 > >=20 > > On 05/09/2016 09:21, Peter Xu wrote: > > > void memory_region_notify_iommu(MemoryRegion *mr, > > > - IOMMUTLBEntry entry) > > > + IOMMUTLBEntry entry, IOMMUAccessFlag= s flag) > > > { > > > assert(memory_region_is_iommu(mr)); > > > + assert(flag =3D=3D mr->iommu_notify_flag); > > > notifier_list_notify(&mr->iommu_notify, &entry); > > > } > >=20 > > Shouldn't it be possible to have IOMMU_RW and IOMMU_NONE on the same > > IOMMU, if the IOMMU supports IOMMU_RW at all? >=20 > Yeah, this is a good point... >=20 > If we see IOMMU_NONE as a subset of IOMMU_RW, we should allow notify > IOMMU_NONE even if the cached flag is IOMMU_RW. >=20 > However in this patch I was not meant to do that. I made it an > exclusive flag to identify two different use cases. I don't know > whether this is good, but at least for Intel IOMMU's current use case, > these two types should be totally isolated from each other: It's not good, it's horrible. This makes a hideous interface that's just a collection of separate use cases without any coherent underlying semantics. > - IOMMU_NONE notification is used by future DMAR-enabled vhost, it > should only be notified with device-IOTLB invalidations, this will > only require "Device IOTLB" capability for Intel IOMMUs, and be > notified in Device IOTLB invalidation handlers. >=20 > - IOMMU_RW notifications should only be used for vfio-pci, notified > with IOTLB invalidations. This will only require Cache Mode (CM=3D1) > capability, and will be notified in common IOTLB invalidations (no > matter whether it's an cache invalidation or not, we will all use > IOMMU_RW flag for this kind of notifies). >=20 > Maybe here naming the flags as IOMMU_{RW_NONE} is a little bit > confusing (just to leverage existing access flags), but what I was > trying to do is to make the two things not overlapped at all, since I > didn't find a mixture use case. Maybe not now, but a common use case is absolutely possible. If you had a single (guest) bus with a single IO address space, with vIOMMU and both VFIO and vhost devices on it, the same vIOMMU would need to send all notifications to VFIO and (at least) unmap notifications to vhost. --=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 --8w3uRX/HFJGApMzv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJXzlG2AAoJEGw4ysog2bOSuIAP/0/WZsnuPglBpIofJZHijEFH XOYNR18jdrh9eK4ghf5mD/Kr7kcOvpo5SwaSINSImPsahK6A6oq9YF34iu/UYbli EBUSRQBozj3VA3yktNzOwO5mFmdgpcvw5AoWBCcALqvZfV9wplRX7t60+Kc14HI9 pWGNf5Wg4HH6EED9DGyZmXQBK+xphv1Rkxo0bZ25x5yAXQZGZIaCdJadzhsMyw+L BHya/oseaEEAYrusw3JZkmwzIvxcd3GMMbSoAlLEtHFFeLPVyeN2i2rAtp/BotG4 9whIM/r2AxyO3fpbF5+q/63hJZfsmKP9vMW2VPDGc1fIdNTmsRSqhlho8kGmKhtl eD31wuUVoULiB6rk/6lCl5gaT/VntCPQ04Be3oeyJCktvRs0aN74rxBPHwQvTsJp +a0FNczwVnniXdhbh10hlEXRskVvYaRVWkMKAi/+IjFCGoyUyHvQTJPJiuA3Wowq yf7uY7hPpaEHEBhcLAZKCv+TYLLCzQc+Dur64Pvevma6MEliZ2sykJ+EzYg10LF+ 2wz3iXfpYPbkrpGKYqixMAfjRHLMcI64RF2Ig7PTzuynuQByjU2Ra8ZgPcJRk0x+ NMDXH9aQ1seMXW1qYaBHHAVqyCvaia5iDzM1dBhFF4GFjyqDd1R8tF09OdSGUTa2 GwC61oc8fUi3jcZLcAX4 =JnZv -----END PGP SIGNATURE----- --8w3uRX/HFJGApMzv--