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.laurion@gmail.com>
a écrit :

> Le mar. 26 janv. 2016 à 05:52, Jan Beulich <JBeulich@suse.com> a écrit :
>
>> >>> On 25.01.16 at 22:49, <thierry.laurion@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
>
>