Sorry for the precedent post that was written a bit too fast. Libreboot was flashed when I wrote it, which is the equivalent of a having vt-d deactivated (iommu=0). Thanks to a user that read this post and wrote to me personally so I could do my mea culpa. Sorry for the precedent misleading post.
Xen on a GM45 chipset and with IGD i915 driver is still getting the system hanged when vt-d is activated. I'm willing to borrow a machine to the Xen developer that could fix the iommu=no-igfx code for gm45 chipset to actually work. A ticket is opened here with current states of thing: https://github.com/QubesOS/qubes-issues/issues/1594#issuecomment-209213917 Sorry about that. Thierry Le dim. 28 févr. 2016 à 14:08, Thierry Laurion <thierry.laur...@gmail.com> a écrit : > The problem wasn't with xen iommu support but kms/drm and i915 driver. > > Passing to the kernel i915.preliminary_hw_support=1 fixes it all :) > > Thanks > > Le sam. 20 févr. 2016 à 22:44, Thierry Laurion <thierry.laur...@gmail.com> > a écrit : > >> 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 >>> >>> >> Here is some interesting lines showing Xen failing without iommu=no-igfx: >> >> --- /home/john/Downloads/amtterm/x200_xen_debug-normal-no_ts.txt >> +++ /home/john/Downloads/amtterm/x200_xen_debug-iommu-no_igfx-no_ts.txt >> @@ -339,23 +339,10 @@ >> (XEN) [VT-D]iommu.c:1465: d0:PCI: map 0000:00:1f.3 >> (XEN) [VT-D]iommu.c:1453: d0:PCIe: map 0000:03:00.0 >> (XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = >> ffff82c000205000 >> -(XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = >> ffff82c000203000 >> +(XEN) [VT-D]iommu.c:719: BIOS did not enable IGD for VT properly. >> Disabling IGD VT-d engine. >> (XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = >> ffff82c000201000 >> (XEN) [VT-D]iommu.c:729: iommu_enable_translation: iommu->reg = >> ffff82c000207000 >> (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs >> -(XEN) [VT-D]iommu.c:873: iommu_fault_status: Fault Overflow >> -(XEN) [VT-D]iommu.c:875: iommu_fault_status: Primary Pending Fault >> -(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr >> ffffff000, iommu reg = ffff82c000203000 >> -(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set >> -(XEN) print_vtd_entries: iommu ffff8301363fa7d0 dev 0000:00:02.0 gmfn >> ffffff >> -(XEN) root_entry = ffff8301363f4000 >> -(XEN) root_entry[0] = 80fa001 >> -(XEN) context = ffff8300080fa000 >> -(XEN) context[10] = 1_8ae0001 >> -(XEN) l3 = ffff830008ae0000 >> -(XEN) l3_index = 3f >> -(XEN) l3[3f] = 0 >> -(XEN) l3[3f] not present >> (XEN) ....................done. >> (XEN) Initial low memory virq threshold set at 0x4000 pages. >> (XEN) Std. Loglevel: All >> >> I restate my comprehension. >> iommu=no-igfx needs to be passed to hypervisor for it to boot. >> iommu=dom0-passthrough would also be needed for dom0 tobe able to unset >> iommu usage for itself? >> >> For Dom0 to have access to device, I also understand that >> intel_iommu=igfx_off kernel option would need to be passed to i915 driver >> of dom0? >> >> Doing so still fails without error. Any hint? >> Doing so by providing dom0-pass >> >>
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
