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
