Re: [Xen-devel] [PATCH v2] VT-d: add iommu=igfx option to workaround graphics issues

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Ting-Wei Lan [mailto:lantw44@xxxxxxxxx]
> Sent: Friday, July 31, 2015 4:38 PM
> 
> Tian, Kevin æ èå2015å07æ31æ 09:26 åé:
> >> From: Ting-Wei Lan [mailto:lantw44@xxxxxxxxx]
> >> Sent: Sunday, July 26, 2015 12:58 AM
> >>
> >> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
> >> devices, It is possible to encounter graphics issues that make screen
> >> unreadable or crash the system. It was reported in freedesktop bugzilla:
> >>
> >> https://bugs.freedesktop.org/show_bug.cgi?id=90037
> >>
> >> As we still cannot find a proper fix for this problem, this patch adds
> >> iommu=igfx option to control whether Intel graphics IOMMU is enabled on
> >> these devices. Running Xen with iommu=no-igfx is similar to running
> >> Linux with intel_iommu=igfx_off, which disables IOMMU for Intel Ironlake
> >> GPU. This can be used by users to manually workaround the problem before
> >> a fix is available for i915 driver.
> >>
> >> Signed-off-by: Ting-Wei Lan <lantw44@xxxxxxxxx>
> >> ---
> >> Changed since v1:
> >>    * Replace igfx_off with igfx
> >>
> >> This patch is currently only build-tested because I don't have access to
> >> the hardware that have graphics issues this week. I will test this new
> >> patch next week.
> >>
> >>   docs/misc/xen-command-line.markdown  | 12 +++++++++++-
> >>   xen/drivers/passthrough/iommu.c      |  3 +++
> >>   xen/drivers/passthrough/vtd/quirks.c |  2 +-
> >>   xen/include/xen/iommu.h              |  2 +-
> >>   4 files changed, 16 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/docs/misc/xen-command-line.markdown
> >> b/docs/misc/xen-command-line.markdown
> >> index 13f03ad..6262be6 100644
> >> --- a/docs/misc/xen-command-line.markdown
> >> +++ b/docs/misc/xen-command-line.markdown
> >> @@ -793,7 +793,7 @@ debug hypervisor only).
> >>   > Default: `new` unless directed-EOI is supported
> >>
> >>   ### iommu
> >> -> `= List of [ <boolean> | force | required | intremap | qinval | snoop | 
> >> sharept |
> >> dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap |
> workaround_bios_bug
> >> | verbose | debug ]`
> >> +> `= List of [ <boolean> | force | required | intremap | qinval | snoop | 
> >> sharept |
> >> dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap |
> workaround_bios_bug
> >> | igfx | verbose | debug ]`
> >>
> >>   > Sub-options:
> >>
> >> @@ -867,6 +867,16 @@ debug hypervisor only).
> >>   >> ignored (normally IOMMU setup fails if any of the devices listed by a 
> >> DRHD
> >>   >> entry aren't PCI discoverable).
> >>
> >> +> `igfx` (VT-d)
> >> +
> >> +> Default: `true`
> >> +
> >> +>> Enable IOMMU for Intel Calpella/Ironlake devices. This option does not
> >> +>> affect grahpics IOMMU on other devices. The intended usage of this 
> >> option
> >> +>> is `no-igfx`, which is silimar to Linux `intel_iommu=igfx_off` option 
> >> used
> >> +>> to workaround graphics issues. If adding `no-igfx` fixes anything, you
> >> +>> should file a bug reporting the problem.
> >> +
> >
> > For above description let's make it general, i.e Enable IOMMU for Intel 
> > Processor
> > Graphics devices. You can list Calpella/Ironlake as the example, but not 
> > the only
> > target. :-)
> 
> no-igfx only works with Calpella/Ironlake because
> is_igd_vt_enabled_quirk() contains this code:
> 
> if ( !IS_ILK(ioh_id) )
>      return 1;
> 

Then let's move the no-igfx check out of this function. 

> The newly added variable iommu_igfx only changes the return value of
> is_igd_vt_enabled_quirk() when IS_ILK(ioh_id) is true. I don't know
> whether we will need no-igfx on other Intel graphics devices because I
> don't many devices to test and I don't have other devices that have this
> problem.
> 

The option itself says nothing Calpella/Ironlake specific, and an user will
intercept it as a general option for all igfx devices so it'd be strange to
see this option no effect on other platform.

Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel