Only dom0 talks directly to the i915 driver, other appvm being pv, which is why I put in question the complete deactivation of IGD by iommu=no-igfx.
Is there anything I can provide to troubleshoot? Le mar. 26 janv. 2016 06:37, Jan Beulich <jbeul...@suse.com> a écrit : > (re-adding xen-devel) > > >>> On 26.01.16 at 12:28, <thierry.laur...@gmail.com> wrote: > > Iommu=0 let the whole Qubes system work, without enforcing hardware > > compartimentalisation (iommu is enforced in software mode) > > > > When iommu=no-igfx is enforced, shell console boot up works flawlessly. > All > > domu machines get booted up. A system hang will happen at the moment a > domu > > machine does graphic rendering, > > 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. > > Jan > > > 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/major > > visual glitch being visible (usb-vm showing device attribution to another > > vm). > > > > Again, if iommu=0 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;stronger > > isolation. > > IGD has a bad history of iommu support. A quick list : > > > > - > http://lists.freedesktop.org/archives/dri-devel/2013-January/033662.html > > -https://lists.ubuntu.com/archives/kernel-team/2013-February/024796.html > > > > Isolation of netvm and usb is a required use case in Qubes. IGD > passthrough > > would be nice to have, but isn't required. I don't really see why someone > > 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 > suffice. > > > > > > Thierry > > > > Le mar. 26 janv. 2016 05:52, Jan Beulich <jbeul...@suse.com> a écrit : > > > >> >>> On 25.01.16 at 22:49, <thierry.laur...@gmail.com> wrote: > >> > The case is 1) disabling iommu for IGD, unilaterally since i915 + gm45 > >> > 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 > side > >> > 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=no-igfx doesn't fix the issue, since remapping > >> 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 > >> > >> > > >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
