From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhUb5-0005Iu-PH for qemu-devel@nongnu.org; Wed, 07 Sep 2016 00:36:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhUb3-00018q-2N for qemu-devel@nongnu.org; Wed, 07 Sep 2016 00:36:26 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:56060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhUb2-00017u-16 for qemu-devel@nongnu.org; Wed, 07 Sep 2016 00:36:24 -0400 Date: Wed, 7 Sep 2016 14:38:16 +1000 From: David Gibson Message-ID: <20160907043816.GL2780@voom.fritz.box> References: <1473060081-17835-1-git-send-email-peterx@redhat.com> <20160906050617.GB16479@voom.fritz.box> <20160906054927.GC21051@pxdev.xzpeter.org> <782f9fec-498d-a121-b961-d9cb9a1c9473@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ucfHZChuBC0NsER/" Content-Disposition: inline In-Reply-To: <782f9fec-498d-a121-b961-d9cb9a1c9473@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/3] memory: add IOMMU notifier type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: Peter Xu , qemu-devel@nongnu.org, mst@redhat.com, vkaplans@redhat.com, alex.williamson@redhat.com, wexu@redhat.com, pbonzini@redhat.com, cornelia.huck@de.ibm.com, dgibson@redhat.com --ucfHZChuBC0NsER/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 06, 2016 at 02:26:44PM +0800, Jason Wang wrote: >=20 >=20 > On 2016=E5=B9=B409=E6=9C=8806=E6=97=A5 13:49, Peter Xu wrote: > > On Tue, Sep 06, 2016 at 03:06:17PM +1000, David Gibson wrote: > > > On Mon, Sep 05, 2016 at 03:21:18PM +0800, Peter Xu wrote: > > > > In the thread: > > > >=20 > > > > https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg00254.h= tml > > > >=20 > > > > Alex proposed a way for vhost DMAR to be enabled without breaking > > > > existing protections on vIOMMU and device assignments. This series > > > > tried to implement the idea, by introducing a IOMMU notifier type f= or > > > > each IOMMU memory region. > > > Hrm, I'm pretty dubious about this concept, since it's basically just > > > an interim hack for an incomplete notifier implementation on x86. > > > What makes just fixing the notifier so difficult? > > Aviv is working on the full notifier support for that. It's been > > months since his last post though. If he cannot continue it (due to > > any reason), I can take it over. But for now, we may still need to > > wait for his patches to fully enable a complete notifier mechanism. >=20 > Yes, and the issue is: >=20 > - There's no way for current intel IOMMU code to be notified when guest m= ap > a page. So it's impossible for intel IOMMU to co-work with vfio now. > - A solution is caching mode (CM) support which requires a TLB invalidati= on > even if it was a non-present to present changing, but this is still under > development. Right. AIUI the whole point of CM is to allow this sort of virtualization. What I hadn't reaalized before was that even with CM=3D=3D0, invalidations were still notified, otherwise I didn't see how anything was possible. > - VT-d spec requires: "Hardware implementations of this architecture must > support operation corresponding to CM=3D0." So even if we have CM mode wh= ich > can work with vfio, we still must support intel IOMMU with CM disabled. It > was not only a spec requirement but also a performance consideration. (CM= is > usually slower) Well.. this isn't a hardware implementation, so I don't think it's really a spec requirement, although I can see why you'd want it so that you can do something as near as possible indistinguishable from hardware. > So in conclusion, there's a mode for intel IOMMU that can't work with vfio > at all. Fixing the notifier does not solve this since the notifier won't = be > able to be triggered. Ok, I understand. CM=3D=3D1 will be able to have the full notifier, but CM=3D=3D0 won't and will never work with VFIO, so we need a way to detect that cleanly. >=20 > >=20 > > I don't know how POWER works to provide a complete notifier, and > > whether POWER can selectively enable the notified items... But for > > Intel VT-d, it provided two choices: by default, only cache > > invalidations are notified (even, we can disalbe cache invaliations), > > but if one want to have a complete notifier, just set the CM bit to 1. > > So I just think it'll be cool if we can support both cases. E.g., for > > vhost, it does not need to be notified with newly added entries, but > > only cache invalidations. IMHO we can't just force vhost to use a > > complete notifier while actually it only needs part of it. > >=20 > > Thanks, > >=20 > > -- peterx >=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 --ucfHZChuBC0NsER/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJXz5m4AAoJEGw4ysog2bOSGEwP/1/M5Trbeu4V+gDEsPiXCYNc Sez6EZ1W4nwc745hnmrpbf57zuPikgrUTzasiauMOLf/M+YTuI5TRRZxx4ZDTWF8 ZDJTgR+fbBRstAWdm5GXVH9OZHfJDlI2iWWYPhN1OPbpeHrP6D3SCxJ77HkoQEQ/ zCI6Bi/Co7OaGoD0qovA0N8glvkUI4C1Qo+gY3PCICv13Wg+aa2Po37pffX+x2Rm /fscl1E/OegUq1OyyX89hBlRJVoGv/9/gzw/uyIX+y8GqcsLJ9ed0Dyk8wEM2cc2 Dx6RuMaP/X4rFcnkT9pUO+kEIQzq7ZzKt5Nm3QaTcPsQihJfpCHgsaAKc9ZDct4j LNmRbWnZ15qxwqXgPgAZqolVy9cG825zmXmz7nU/toB4hHN17D4jxLGsYzf9vM+e ndVMWtekS5JsK7HOgB7nQBKwFiglqpuHDGVirTCoyC0upisfFHBucQGRivp3yS4J iEiktnd+rPclCeFDVHd9ySXQNf51i4rUQ0JvgJJ5tt+i1togq/G/8iEVX63PZSjy 5K01Uk5aZNj81poFBDWkrzpLQaTPewl4L6Uam54DQKvadwMgyW/WNHy/LwnGW8qN dgqatgtUs8N2/1oAri7ZJmZ9x9ZjUGSH5X/2yELc3K1yhcW14QTq9UT6AkdpTq+B h5YGQO+2FrvxqvDB1rr9 =X4rF -----END PGP SIGNATURE----- --ucfHZChuBC0NsER/--