From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Re: pre Sandy bridge IOMMU support (gm45) Date: Sat, 30 Jan 2016 02:47:58 +0100 Message-ID: <20160130014758.GA24446@mail-itl> References: <56A63F9502000078000CAAD1@prv-mh.provo.novell.com> <56A75DF402000078000CAFAF@prv-mh.provo.novell.com> <56A7687102000078000CB035@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1910706128108111534==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aPKdy-0005uM-9V for xen-devel@lists.xenproject.org; Sat, 30 Jan 2016 01:48:06 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7DC4B22E52 for ; Fri, 29 Jan 2016 20:48:03 -0500 (EST) In-Reply-To: <56A7687102000078000CB035@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Thierry Laurion List-Id: xen-devel@lists.xenproject.org --===============1910706128108111534== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline --9amGYk9869ThD9tj Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 26, 2016 at 04:37:05AM -0700, Jan Beulich wrote: > (re-adding xen-devel) >=20 > >>> On 26.01.16 at 12:28, wrote: > > Iommu=3D0 let the whole Qubes system work, without enforcing hardware > > compartimentalisation (iommu is enforced in software mode) > >=20 > > When iommu=3Dno-igfx is enforced, shell console boot up works flawlessl= y. All > > domu machines get booted up. A system hang will happen at the moment a = domu > > machine does graphic rendering, >=20 > And this is (other than I originally implied) without passing through > the IGD to the DomU? If so, I can't see the difference between a > guest rendering to its display (and vncviewer or whatever frontend > you use converting this to rendering on the host) and rendering > which originates in the host. Not sure if relevant, but window content is mapped from PV domU directly into X server (in dom0) address space, using xc_map_foreign_pages. It is done by hacking XShmAttach function. Not sure what graphics driver do with it next. Theoretically it could be possible that driver will direct IGD to do DMA directly from that place, but I guess it does not. >=20 > Jan >=20 > > which often results in tray icon being > > fuzzy just before the system gets unresponsive(netvm showing it get > > connected through nm - applet rendering) , or a notification starting to > > show up while the system hangs before it disappears with some minor/maj= or > > visual glitch being visible (usb-vm showing device attribution to anoth= er > > vm). > >=20 > > Again, if iommu=3D0 is passed to xen, there is no system hang while not > > having any added isolation security from usb devices being in a domu and > > network devices being in another one, while applications sit in seperate > > ones. This is why Qubes strongly suggest but doesn't require iommu;stro= nger > > isolation. > > IGD has a bad history of iommu support. A quick list : > >=20 > > -http://lists.freedesktop.org/archives/dri-devel/2013-January/033662.ht= ml=20 > > -https://lists.ubuntu.com/archives/kernel-team/2013-February/024796.htm= l=20 > >=20 > > Isolation of netvm and usb is a required use case in Qubes. IGD passthr= ough > > would be nice to have, but isn't required. I don't really see why someo= ne > > would want to passthrouh IGD to a Windows domu, gm45 based laptops are > > definitely not gaming laptops. Since i915 and gm45 have a bad iommu > > history, just being able to completely disable iommu for IGD would suff= ice. > >=20 > >=20 > > Thierry > >=20 > > Le mar. 26 janv. 2016 05:52, Jan Beulich a =C3=A9cr= it : > >=20 > >> >>> On 25.01.16 at 22:49, wrote: > >> > The case is 1) disabling iommu for IGD, unilaterally since i915 + gm= 45 > >> > doesn't play well together. Iommu is still desired to isolate usb and > >> > network devices, so we don't want to disable iommu completely. The s= ide > >> > effect of this would be to have IGD only for dom0, which would also > >> > completely make sense in this use case. > >> > > >> > The point is the iommu=3Dno-igfx doesn't fix the issue, since remapp= ing > >> seems > >> > to still happen for IGD. Does that make sense ? > >> > >> It certainly may make sense, just that in what you have written so > >> far I don't think I've been able to spot any evidence thereof. Since, > >> as you say, nothing interesting gets logged by Xen, you must be > >> drawing this conclusion from something (or else you wouldn't say > >> "doesn't fix the issue"). > >> > >> Jan > >> > >> >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --9amGYk9869ThD9tj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWrBZQAAoJENuP0xzK19csSfIIAJH8i4RlxAjO9B9nOBHEDJkm AUhOGoOcg+yRzMG38Kqj5nauIetQwxSs/QUhEasbAwpqVvAXdYKsrDC1b1LZI7rj SD63Ci5o7JVR+3vwiWhyZIw8njAaRVuTkJJv0QH+6ygJBjd7e4Lk34mtpfwBgbCn WCy940PFZ7HLooPEA7ljUM571BWFcGfu8ZvWYOWqYFlmOyAfutum+X/YlC5yI/EZ EV6tej/iPWKAbML7UqpIy9dy2r4iM4IUJ8QeBgBhZGJguCEWkR0aK6lPNjQX3t+d evpTVAlWASas4UnXJ1NjcH6D7FB6t2CEpj45SNCQl2zb7VuNZ+4YpcAp4WGVv+Q= =s0hK -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- --===============1910706128108111534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1910706128108111534==--