Re: [Xen-devel] pre Sandy bridge IOMMU support (gm45)

[Thierry Laurion <thierry.laurion@xxxxxxxxx>]

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

Le mar. 26 janv. 2016 à 05:52, Jan Beulich <JBeulich@xxxxxxxx> a écrit :

>>> On 25.01.16 at 22:49, <thierry.laurion@xxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel