diff mbox

pre Sandy bridge IOMMU support (gm45)

Message ID CAAzJznxS6zKsCiFnKiW=5WzU3oO9D2RF0-o3X3Bzz4kR_nfXrw@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Thierry Laurion Feb. 21, 2016, 3:45 a.m. UTC 
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:

-(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

Comments

Thierry Laurion Feb. 28, 2016, 7:08 p.m. UTC | #1 
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
>
>
Thierry Laurion June 26, 2016, 11:47 p.m. UTC | #2 
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@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.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
>>
>>
diff mbox

Patch

--- /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