[Xen-devel] [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled
When using Linux >= 3.19 as the dom0 kernel, characters on the screen become broken after the graphic driver is loaded. The commit that breaks it is (found by git bisect): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47591df Screenshot when the system run in single user mode: https://bugs.freedesktop.org/attachment.cgi?id=115079 If it continues booting, the dom0 can crash after GDM tries to start Xorg. Some messages are showed when Xorg is running: [ 80.636446] [drm] stuck on render ring [ 80.640041] [drm] GPU HANG: ecode 5:0:0x7fbfff08, in Xwayland [2112], reason: Ring hung, action: reset I cannot run 'dmesg' and 'xl dmesg' because the dom0 is unusable after Xorg runs, so I attach the serial console log instead. It was tested on Xen 4.5.1-rc2 and Linux 4.1-rc7: https://gist.github.com/lantw44/715160f1a53967a1627b This problem was reported to DRM/Intel, but they think it is not their bug. I also reported it to kernel bugzilla, but there is no response: https://bugs.freedesktop.org/show_bug.cgi?id=90037 https://bugzilla.kernel.org/show_bug.cgi?id=97421 This problem only happens when VT-d is enabled. If I add 'iommu=off' to Xen boot arguments, there will be no problem. It seems it only happens on specific hardware. Two machines are listed below, one with the problem and one without the problem. The machine that has this problem: (Software) Xen 4.4.2, 4.5.0, 4.5.1-rc2 Linux 3.19.2, 3.19.3, 3.19.4, 4.0, 4.0.3, 4.0.4, 4.1-rc7 (CPU and GPU) Intel Core i5 CPU 650 @ 3.20GHz Intel Ironlake Desktop (Motherboard) ASUSTeK Computer INC. P7H55D-M EVO (lspci output) 00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 12) 00:01.0 PCI bridge: Intel Corporation Core Processor PCI Express x16 Root Port (rev 12) 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12) 00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06) 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06) 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06) 00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 06) 00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 (rev 06) 00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 (rev 06) 00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 5 (rev 06) 00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 6 (rev 06) 00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) 00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 06) 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 06) 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06) 01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II / PATA Controller (rev b2) 05:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller 06:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) 3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02) 3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02) 3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02) 3f:02.1 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor QPI Physical 0 (rev 02) 3f:02.2 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved (rev 02) 3f:02.3 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved (rev 02) The machine that works fine: (Software) Xen 4.4.1, 4.4.2 Linux 3.19.1, 3.19.2, 3.19.3, 3.19.7, 4.0.4 (CPU and GPU) Intel Core i7-2600 CPU @ 3.40GHz Intel Sandybridge Desktop (Motherboard) ASUSTeK Computer INC. P8Z68-M PRO (lspci output) 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller
Re: [Xen-devel] Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled
於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到： > On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan wrote: > > When using Linux >= 3.19 as the dom0 kernel, characters on the > > screen become > > broken after the graphic driver is loaded. The commit that breaks > > it is > > (found by git bisect): > > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com > > mit/?id=47591df > > Lets CC Juergen > > > > > > Screenshot when the system run in single user mode: > > > > https://bugs.freedesktop.org/attachment.cgi?id=115079 > > > > > > If it continues booting, the dom0 can crash after GDM tries to > > start Xorg. > > Some messages are showed when Xorg is running: > > > > [ 80.636446] [drm] stuck on render ring > > [ 80.640041] [drm] GPU HANG: ecode 5:0:0x7fbfff08, in Xwayland > > [2112], > > reason: Ring hung, action: reset > > > > > > I cannot run 'dmesg' and 'xl dmesg' because the dom0 is unusable > > after Xorg > > runs, so I attach the serial console log instead. It was tested on > > Xen > > 4.5.1-rc2 and Linux 4.1-rc7: > > > > https://gist.github.com/lantw44/715160f1a53967a1627b > > > > > > This problem was reported to DRM/Intel, but they think it is not > > their bug. > > I also reported it to kernel bugzilla, but there is no response: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=90037 > > https://bugzilla.kernel.org/show_bug.cgi?id=97421 > > > > > > This problem only happens when VT-d is enabled. If I add > > 'iommu=off' to Xen > > boot arguments, there will be no problem. It seems it only happens > > on > > specific hardware. Two machines are listed below, one with the > > problem and > > one without the problem. > > Could you also include your .config file please? > My .config for Linux 4.0.4 https://gist.github.com/lantw44/5cbfc6e6052423bec910 It should be the same as the kernel provided by Fedora 22 except for CONFIG_XEN_PVH=y. > > > > > > The machine that has this problem: > > > > (Software) > > Xen 4.4.2, 4.5.0, 4.5.1-rc2 > > Linux 3.19.2, 3.19.3, 3.19.4, 4.0, 4.0.3, 4.0.4, 4.1-rc7 > > > > (CPU and GPU) > > Intel Core i5 CPU 650 @ 3.20GHz > > Intel Ironlake Desktop > > > > (Motherboard) > > ASUSTeK Computer INC. P7H55D-M EVO > > > > (lspci output) > > 00:00.0 Host bridge: Intel Corporation Core Processor DRAM > > Controller (rev > > 12) > > 00:01.0 PCI bridge: Intel Corporation Core Processor PCI Express > > x16 Root > > Port (rev 12) > > 00:02.0 VGA compatible controller: Intel Corporation Core Processor > > Integrated Graphics Controller (rev 12) > > 00:16.0 Communication controller: Intel Corporation 5 Series/3400 > > Series > > Chipset HECI Controller (rev 06) > > 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series > > Chipset USB2 > > Enhanced Host Controller (rev 06) > > 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series > > Chipset High > > Definition Audio (rev 06) > > 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset > > PCI > > Express Root Port 1 (rev 06) > > 00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset > > PCI > > Express Root Port 2 (rev 06) > > 00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset > > PCI > > Express Root Port 3 (rev 06) > > 00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset > > PCI > > Express Root Port 4 (rev 06) > > 00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset > > PCI > > Express Root Port 5 (rev 06) > > 00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset > > PCI > > Express Root Port 6 (rev 06) > > 00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series > > Chipset USB2 > > Enhanced Host Controller (rev 06) > > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) > > 00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC > > Interface > > Controller (rev 06) > > 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series > > Chipset 6 > > port SATA AHCI Controller (rev 06) > > 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus > > Controller (rev 06) > > 01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host > > Controller > > (rev 03) > >
Re: [Xen-devel] Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled
Juergen Gross 於 西元2015年06月16日 12:30 寫道: On 06/15/2015 09:03 PM, Ting-Wei Lan wrote: 於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到： On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan wrote: When using Linux >= 3.19 as the dom0 kernel, characters on the screen become broken after the graphic driver is loaded. The commit that breaks it is (found by git bisect): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com mit/?id=47591df Lets CC Juergen Screenshot when the system run in single user mode: https://bugs.freedesktop.org/attachment.cgi?id=115079 Are those messages to be expected: (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs (XEN) [VT-D]DMAR:[DMA Write] Request device [:00:02.0] fault addr b61eef000, iommu reg = 82c000203000 (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set (XEN) ..done. I'm not familiar with VT-D internals, but seeing these messages for the video device during RAM scrubbing makes wonder if everything is correct regarding the VT-D and memory setup... I got more VT-D messages by using iommu=verbose: Loading Xen 4.5.1-rc2 ... Loading Linux 4.0.5-300.fc22.x86_64 ... Loading initial ramdisk ... Xen 4.5.1-rc2 (XEN) Xen version 4.5.1-rc2 (nobody@[unknown]) (gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)) debug=n Thu Jun 11 02:48:49 EDT 2015 (XEN) Latest ChangeSet: Wed Jun 3 09:10:15 2015 +0200 git:0f4362b (XEN) Bootloader: GRUB 2.02~beta2 (XEN) Command line: placeholder com1=115200,8n1 console=vga,com1 conswitch=a loglvl=all guest_loglvl=all iommu=verbose (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) - 0009c800 (usable) (XEN) 0009c800 - 000a (reserved) (XEN) 000e4000 - 0010 (reserved) (XEN) 0010 - d7a7 (usable) (XEN) d7a7 - d7a88000 (ACPI data) (XEN) d7a88000 - d7adc000 (ACPI NVS) (XEN) d7adc000 - e000 (reserved) (XEN) fee0 - fee01000 (reserved) (XEN) ff80 - 0001 (reserved) (XEN) 0001 - 0003fc00 (usable) (XEN) 0003fc00 - 0004 (reserved) (XEN) 0004 - 00042000 (usable) (XEN) ACPI: RSDP 000FB9E0, 0014 (r0 ACPIAM) (XEN) ACPI: RSDT D7A7, 0048 (r1 072210 RSDT1556 20100722 MSFT 97) (XEN) ACPI: FACP D7A70200, 0084 (r1 072210 FACP1556 20100722 MSFT 97) (XEN) ACPI: DSDT D7A704A0, D67C (r1 A1471 A14710011 INTL 20060113) (XEN) ACPI: FACS D7A88000, 0040 (XEN) ACPI: APIC D7A70390, 00CC (r1 072210 APIC1556 20100722 MSFT 97) (XEN) ACPI: MCFG D7A70460, 003C (r1 072210 OEMMCFG 20100722 MSFT 97) (XEN) ACPI: OEMB D7A88040, 0072 (r1 072210 OEMB1556 20100722 MSFT 97) (XEN) ACPI: HPET D7A7DB20, 0038 (r1 072210 OEMHPET 20100722 MSFT 97) (XEN) ACPI: GSCI D7A880C0, 2024 (r1 072210 GMCHSCI 20100722 MSFT 97) (XEN) ACPI: DMAR D7A8A0F0, 00E0 (r1AMI OEMDMAR1 MSFT 97) (XEN) ACPI: OSFR D7A7DB60, 00B0 (r1 072210 OEMOSFR 20100722 MSFT 97) (XEN) ACPI: SSDT D7A8BC00, 0363 (r1 DpgPmmCpuPm 12 INTL 20060113) (XEN) System RAM: 16186MB (16574512kB) (XEN) No NUMA configuration found (XEN) Faking a node at -00042000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000ff780 (XEN) DMI 2.6 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:804,1:0], pm1x_evt[1:800,1:0] (XEN) ACPI: wakeup_vec[d7a8800c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee0 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 6:5 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) (XEN) Processor #4 6:5 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled) (XEN) Processor #1 6:5 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x05] enabled) (XEN) Processor #5 6:5 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled) (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled) (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x86] disabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x87] disabled) (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x8b] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x8c] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x8d] disabled) (XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x8e] disabled) (XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x8f] disabled) (XEN) ACPI: IOAPIC (id[0x06]
Re: [Xen-devel] Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with VT-d enabled
於 二，2015-06-16 於 11:58 +0200，Juergen Gross 提到： > On 06/16/2015 11:32 AM, 藍挺瑋 wrote: > > 於 二，2015-06-16 於 11:06 +0200，Juergen Gross 提到： > > > On 06/16/2015 10:55 AM, Ting-Wei Lan wrote: > > > > Juergen Gross 於 西元2015年06月16日 12:30 寫道: > > > > > On 06/15/2015 09:03 PM, Ting-Wei Lan wrote: > > > > > > 於 一，2015-06-15 於 14:55 -0400，Konrad Rzeszutek Wilk 提到： > > > > > > > On Sat, Jun 13, 2015 at 12:43:14AM +0800, Ting-Wei Lan > > > > > > > wrote: > > > > > > > > When using Linux >= 3.19 as the dom0 kernel, characters > > > > > > > > on > > > > > > > > the > > > > > > > > screen become > > > > > > > > broken after the graphic driver is loaded. The commit > > > > > > > > that > > > > > > > > breaks > > > > > > > > it is > > > > > > > > (found by git bisect): > > > > > > > > > > > > > > > > > > > > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/l > > > > > > > > inux > > > > > > > > .git/com > > > > > > > > mit/?id=47591df > > > > > > > > > > > > > > Lets CC Juergen > > > > > > > > > > > > > > > > > > > > > > > > Screenshot when the system run in single user mode: > > > > > > > > > > > > > > > > > > > > > > > > https://bugs.freedesktop.org/attachment.cgi?id=115079 > > > > > > > > > > Are those messages to be expected: > > > > > > > > > > (XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs > > > > > (XEN) [VT-D]DMAR:[DMA Write] Request device [:00:02.0] > > > > > fault > > > > > addr > > > > > b61eef000, iommu reg = 82c000203000 > > > > > (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set > > > > > (XEN) > > > > > . > > > > > > > > > > .done. > > > > > > > > > > I'm not familiar with VT-D internals, but seeing these > > > > > messages > > > > > for the > > > > > video device during RAM scrubbing makes wonder if everything > > > > > is > > > > > correct > > > > > regarding the VT-D and memory setup... > > > ... > > > > > > > > I still remember that there was a similar problem found > > > > > > > > two > > > > > > > > years > > > > > > > > ago on the > > > > > > > > same hardware with similar broken screen output and it > > > > > > > > also > > > > > > > > crashed > > > > > > > > after > > > > > > > > Xorg was started, but I cannot confirm that they are > > > > > > > > the > > > > > > > > same > > > > > > > > problems. I > > > > > > > > don't know whether error messages are simliar. > > > > > > > > > > > > > > > > The old problem happens on Linux 3.7 ~ 3.10 with VT-d > > > > > > > > enabled. It > > > > > > > > only > > > > > > > > happened when not using Xen, so I added > > > > > > > > 'intel_iommu=off' > > > > > > > > to Linux > > > > > > > > boot > > > > > > > > arguments to workaround it. > > > > > > > > > > Hmm, do you see any chance in finding the commit which made > > > > > it > > > > > working > > > > > again? Perhaps there was some workaround for this hardware > > > > > which > > > > > is > > > > > missing in Xen now... > > > > > > > > After some tests, I found the information I provided before was > > > > incorrect. It seems the problem happens on all Linux >= 3.7, > > > > including > > > > Linux 4.0.5, so the old problem was never fixed. Here are some > > > > 'dmesg | > > > > grep -i iommu' outputs. > > > > > > So a Xen-specific error is rather improbable, correct? > > > > But Linux provides 'intel_iommu=igfx_off' to workaround the > > problem. > > Does Xen provide similar things? > > Not that I know of. The question is whether you really need VT-d, and > if > yes, why. You could still switch the iommu off for dom0 by setting > iommu=dom0-passthrough in the Xen command line (your hardware might > not > support it, though). iommu=dom0-passthrough doesn't work on my hardware. I found a workaround for my hardware: diff --git a/xen/drivers/passthrough/vtd/quirks.c b/xen/drivers/passthrough/vtd/quirks.c index 69d29ab..b937ad0 100644 --- a/xen/drivers/passthrough/vtd/quirks.c +++ b/xen/drivers/passthrough/vtd/quirks.c @@ -74,6 +74,7 @@ int is_igd_vt_enabled_quirk(void) if ( !IS_ILK(ioh_id) ) return 1; +return 0; /* integrated graphics on Intel platforms is located at 0:2.0 */ ggc = pci_conf_read16(0, 0, IGD_DEV, 0, GGC); This workaround is silimar to intel_iommu=igfx_off in Linux. I found silimar code in function quirk_calpella_no_shadow_gtt in drivers/iommu/intel-iommu.c. I reported the graphics corruption problems on Linux >= 3.7 here: https://bugs.freedesktop.org/show_bug.cgi?id=91127 And here is the bug link of Xen and Linux >= 3.19 (the bug we are discussing here): https://bugs.freedesktop.org/show_bug.cgi?id=90037 I hope we can get a real fix. > > > Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] VT-d: add iommu=igfx option to workaround graphics issues
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.
Running Xen with iommu=no-igfx is similar to running Linux with
intel_iommu=igfx_off, which disables IOMMU for Intel 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
Reviewed-by: Andrew Cooper
---
Changed since v2:
* Make no-igfx available for all Intel devices, not just Calpella/Ironlake
Changed since v1:
* Replace igfx_off with igfx
docs/misc/xen-command-line.markdown | 11 ++-
xen/drivers/passthrough/iommu.c | 3 +++
xen/drivers/passthrough/vtd/quirks.c | 3 +++
xen/include/xen/iommu.h | 2 +-
4 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 13f03ad..486e53b 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 [ | force | required | intremap | qinval | snoop |
sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap |
workaround_bios_bug | verbose | debug ]`
+> `= List of [ | 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,15 @@ 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 graphics 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.
+
> `verbose`
> Default: `false`
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index cc12735..966cc66 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -47,6 +47,7 @@ bool_t __read_mostly force_iommu;
bool_t __hwdom_initdata iommu_dom0_strict;
bool_t __read_mostly iommu_verbose;
bool_t __read_mostly iommu_workaround_bios_bug;
+bool_t __read_mostly iommu_igfx = 1;
bool_t __read_mostly iommu_passthrough;
bool_t __read_mostly iommu_snoop = 1;
bool_t __read_mostly iommu_qinval = 1;
@@ -87,6 +88,8 @@ static void __init parse_iommu_param(char *s)
force_iommu = val;
else if ( !strcmp(s, "workaround_bios_bug") )
iommu_workaround_bios_bug = val;
+else if ( !strcmp(s, "igfx") )
+iommu_igfx = val;
else if ( !strcmp(s, "verbose") )
iommu_verbose = val;
else if ( !strcmp(s, "snoop") )
diff --git a/xen/drivers/passthrough/vtd/quirks.c
b/xen/drivers/passthrough/vtd/quirks.c
index 69d29ab..92cff1d 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -72,6 +72,9 @@ int is_igd_vt_enabled_quirk(void)
{
u16 ggc;
+if ( !iommu_igfx )
+return 0;
+
if ( !IS_ILK(ioh_id) )
return 1;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8eb764a..29eed51 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -29,7 +29,7 @@
extern bool_t iommu_enable, iommu_enabled;
extern bool_t force_iommu, iommu_verbose;
-extern bool_t iommu_workaround_bios_bug, iommu_passthrough;
+extern bool_t iommu_workaround_bios_bug, iommu_igfx, iommu_passthrough;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;
extern bool_t iommu_hap_pt_share;
extern bool_t iommu_debug;
--
2.4.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4] VT-d: add iommu=igfx option to workaround graphics issues
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.
Running Xen with iommu=no-igfx is similar to running Linux with
intel_iommu=igfx_off, which disables IOMMU for Intel 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
Reviewed-by: Andrew Cooper
Release-acked-by: Wei Liu
---
Changed since v3:
* Fix typo in xen-command-line.markdown
Changed since v2:
* Make no-igfx available for all Intel devices, not just Calpella/Ironlake
Changed since v1:
* Replace igfx_off with igfx
docs/misc/xen-command-line.markdown | 11 ++-
xen/drivers/passthrough/iommu.c | 3 +++
xen/drivers/passthrough/vtd/quirks.c | 3 +++
xen/include/xen/iommu.h | 2 +-
4 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 13f03ad..a01292a 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 [ | force | required | intremap | qinval | snoop |
sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap |
workaround_bios_bug | verbose | debug ]`
+> `= List of [ | 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,15 @@ 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 graphics devices. The intended usage of this option
+>> is `no-igfx`, which is similar 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.
+
> `verbose`
> Default: `false`
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index cc12735..966cc66 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -47,6 +47,7 @@ bool_t __read_mostly force_iommu;
bool_t __hwdom_initdata iommu_dom0_strict;
bool_t __read_mostly iommu_verbose;
bool_t __read_mostly iommu_workaround_bios_bug;
+bool_t __read_mostly iommu_igfx = 1;
bool_t __read_mostly iommu_passthrough;
bool_t __read_mostly iommu_snoop = 1;
bool_t __read_mostly iommu_qinval = 1;
@@ -87,6 +88,8 @@ static void __init parse_iommu_param(char *s)
force_iommu = val;
else if ( !strcmp(s, "workaround_bios_bug") )
iommu_workaround_bios_bug = val;
+else if ( !strcmp(s, "igfx") )
+iommu_igfx = val;
else if ( !strcmp(s, "verbose") )
iommu_verbose = val;
else if ( !strcmp(s, "snoop") )
diff --git a/xen/drivers/passthrough/vtd/quirks.c
b/xen/drivers/passthrough/vtd/quirks.c
index 69d29ab..92cff1d 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -72,6 +72,9 @@ int is_igd_vt_enabled_quirk(void)
{
u16 ggc;
+if ( !iommu_igfx )
+return 0;
+
if ( !IS_ILK(ioh_id) )
return 1;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8eb764a..29eed51 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -29,7 +29,7 @@
extern bool_t iommu_enable, iommu_enabled;
extern bool_t force_iommu, iommu_verbose;
-extern bool_t iommu_workaround_bios_bug, iommu_passthrough;
+extern bool_t iommu_workaround_bios_bug, iommu_igfx, iommu_passthrough;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;
extern bool_t iommu_hap_pt_share;
extern bool_t iommu_debug;
--
2.4.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Work-arounds in Xen code for Intel GFX?Re: Is: graphics corruption with 'xen: Support Xen pv-domains using PAT." Was:Re: [BUG] Characters on the screen are broken on Linux >= 3.19 with
> > > > But Linux provides 'intel_iommu=igfx_off' to workaround the > > > > problem. > > > > Does Xen provide similar things? > > > > > > Not that I know of. The question is whether you really need VT-d, > > > and > > > if > > > yes, why. You could still switch the iommu off for dom0 by > > > setting > > > iommu=dom0-passthrough in the Xen command line (your hardware > > > might > > > not > > > support it, though). > > > > iommu=dom0-passthrough doesn't work on my hardware. > > > > I found a workaround for my hardware: > > > > diff --git a/xen/drivers/passthrough/vtd/quirks.c > > b/xen/drivers/passthrough/vtd/quirks.c > > index 69d29ab..b937ad0 100644 > > --- a/xen/drivers/passthrough/vtd/quirks.c > > +++ b/xen/drivers/passthrough/vtd/quirks.c > > @@ -74,6 +74,7 @@ int is_igd_vt_enabled_quirk(void) > > > > if ( !IS_ILK(ioh_id) ) > > return 1; > > +return 0; > > > > /* integrated graphics on Intel platforms is located at 0:2.0 > > */ > > ggc = pci_conf_read16(0, 0, IGD_DEV, 0, GGC); > > Lets CC the maintaners of said code. > > > > > > This workaround is silimar to intel_iommu=igfx_off in Linux. I > > found > > silimar code in function quirk_calpella_no_shadow_gtt in > > drivers/iommu/intel-iommu.c. As I don't know how to properly fix the problem, I made a patch to add iommu=igfx_off option to workaround the issue in Xen. https://gist.github.com/lantw44/9f8a94d2eeb846889a5a Is this patch acceptable, or we should wait for a fix instead? > > > > > > I reported the graphics corruption problems on Linux >= 3.7 here: > > https://bugs.freedesktop.org/show_bug.cgi?id=91127 It was partially fixed by this commit (available in Linux 4.2-rc2): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ ?id=8b572a4 But it seems it cannot be ported to Xen. > > > > And here is the bug link of Xen and Linux >= 3.19 (the bug we are > > discussing here): > > https://bugs.freedesktop.org/show_bug.cgi?id=90037 > > > > I hope we can get a real fix. > > > > > > > > > > > > > Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] build: use correct qemu path in systemd service file and init script
When --with-system-qemu is used, it is possible that we cannot find
qemu-system-i386 in LIBEXEC_BIN, which can cause error in xencommons
init script and xen-qemu-dom0-disk-backend.service systemd service.
---
tools/configure | 11 +++
tools/configure.ac| 6 ++
tools/hotplug/Linux/init.d/sysconfig.xencommons.in| 2 +-
tools/hotplug/Linux/init.d/xencommons.in | 2 +-
.../Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 2 +-
5 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/tools/configure b/tools/configure
index 2fa7426..c7ac612 100755
--- a/tools/configure
+++ b/tools/configure
@@ -695,6 +695,7 @@ PREPEND_INCLUDES
EXTRA_QEMUU_CONFIGURE_ARGS
ovmf_path
seabios_path
+qemu_xen_path_service
qemu_xen
rombios
qemu_traditional
@@ -4168,6 +4169,16 @@ _ACEOF
fi
+if test "x$qemu_xen_path" = "x" || test "x$qemu_xen_path" = "xqemu"; then :
+
+qemu_xen_path_service="$LIBEXEC_BIN/qemu-system-i386"
+
+else
+
+qemu_xen_path_service="$withval"
+
+fi
+
diff --git a/tools/configure.ac b/tools/configure.ac
index b7f1513..3bb2b8b 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -199,7 +199,13 @@ AC_ARG_WITH([system-qemu],
AS_IF([test "x$qemu_xen" = "xn"], [
AC_DEFINE_UNQUOTED([QEMU_XEN_PATH], ["$qemu_xen_path"], [Qemu Xen path])
])
+AS_IF([test "x$qemu_xen_path" = "x" || test "x$qemu_xen_path" = "xqemu"], [
+qemu_xen_path_service="$LIBEXEC_BIN/qemu-system-i386"
+], [
+qemu_xen_path_service="$withval"
+])
AC_SUBST(qemu_xen)
+AC_SUBST(qemu_xen_path_service)
AC_ARG_WITH([system-seabios],
AS_HELP_STRING([--with-system-seabios@<:@=PATH@:>@],
diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index c12fc8a..770ba90 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -39,4 +39,4 @@
#XENBACKENDD_DEBUG=[yes|on|1]
# qemu path
-#QEMU_XEN=@LIBEXEC_BIN@/qemu-system-i386
+#QEMU_XEN=@qemu_xen_path_service@
diff --git a/tools/hotplug/Linux/init.d/xencommons.in
b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..b501aaf 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -98,7 +98,7 @@ do_start () {
test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS="
--log=$XENCONSOLED_TRACE"
${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
echo Starting QEMU as disk backend for dom0
- test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC_BIN}/qemu-system-i386"
+ test -z "$QEMU_XEN" && QEMU_XEN="@qemu_xen_path_service@"
$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
-daemonize \
-monitor /dev/null -serial /dev/null -parallel /dev/null \
-pidfile $QEMU_PIDFILE
diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
index 274cec0..a8e2ca0 100644
--- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
+++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
@@ -11,7 +11,7 @@ Type=simple
PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
-ExecStart=@LIBEXEC_BIN@/qemu-system-i386 -xen-domid 0 \
+ExecStart=@qemu_xen_path_service@ -xen-domid 0 \
-xen-attach -name dom0 -nographic -M xenpv -daemonize \
-monitor /dev/null -serial /dev/null -parallel /dev/null \
-pidfile @XEN_RUN_DIR@/qemu-dom0.pid
--
2.4.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] build: use correct qemu path in systemd service file and init script
When --with-system-qemu is used, it is possible that we cannot find
qemu-system-i386 in LIBEXEC_BIN, which can cause error in xencommons
init script and xen-qemu-dom0-disk-backend.service systemd service.
Signed-off-by: Ting-Wei Lan
---
tools/configure | 11 +++
tools/configure.ac| 6 ++
tools/hotplug/Linux/init.d/sysconfig.xencommons.in| 2 +-
tools/hotplug/Linux/init.d/xencommons.in | 2 +-
.../Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 2 +-
5 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/tools/configure b/tools/configure
index 2fa7426..c7ac612 100755
--- a/tools/configure
+++ b/tools/configure
@@ -695,6 +695,7 @@ PREPEND_INCLUDES
EXTRA_QEMUU_CONFIGURE_ARGS
ovmf_path
seabios_path
+qemu_xen_path_service
qemu_xen
rombios
qemu_traditional
@@ -4168,6 +4169,16 @@ _ACEOF
fi
+if test "x$qemu_xen_path" = "x" || test "x$qemu_xen_path" = "xqemu"; then :
+
+qemu_xen_path_service="$LIBEXEC_BIN/qemu-system-i386"
+
+else
+
+qemu_xen_path_service="$withval"
+
+fi
+
diff --git a/tools/configure.ac b/tools/configure.ac
index b7f1513..3bb2b8b 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -199,7 +199,13 @@ AC_ARG_WITH([system-qemu],
AS_IF([test "x$qemu_xen" = "xn"], [
AC_DEFINE_UNQUOTED([QEMU_XEN_PATH], ["$qemu_xen_path"], [Qemu Xen path])
])
+AS_IF([test "x$qemu_xen_path" = "x" || test "x$qemu_xen_path" = "xqemu"], [
+qemu_xen_path_service="$LIBEXEC_BIN/qemu-system-i386"
+], [
+qemu_xen_path_service="$withval"
+])
AC_SUBST(qemu_xen)
+AC_SUBST(qemu_xen_path_service)
AC_ARG_WITH([system-seabios],
AS_HELP_STRING([--with-system-seabios@<:@=PATH@:>@],
diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index c12fc8a..770ba90 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -39,4 +39,4 @@
#XENBACKENDD_DEBUG=[yes|on|1]
# qemu path
-#QEMU_XEN=@LIBEXEC_BIN@/qemu-system-i386
+#QEMU_XEN=@qemu_xen_path_service@
diff --git a/tools/hotplug/Linux/init.d/xencommons.in
b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..b501aaf 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -98,7 +98,7 @@ do_start () {
test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS="
--log=$XENCONSOLED_TRACE"
${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
echo Starting QEMU as disk backend for dom0
- test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC_BIN}/qemu-system-i386"
+ test -z "$QEMU_XEN" && QEMU_XEN="@qemu_xen_path_service@"
$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
-daemonize \
-monitor /dev/null -serial /dev/null -parallel /dev/null \
-pidfile $QEMU_PIDFILE
diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
index 274cec0..a8e2ca0 100644
--- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
+++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
@@ -11,7 +11,7 @@ Type=simple
PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
-ExecStart=@LIBEXEC_BIN@/qemu-system-i386 -xen-domid 0 \
+ExecStart=@qemu_xen_path_service@ -xen-domid 0 \
-xen-attach -name dom0 -nographic -M xenpv -daemonize \
-monitor /dev/null -serial /dev/null -parallel /dev/null \
-pidfile @XEN_RUN_DIR@/qemu-dom0.pid
--
2.4.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] VT-d: add iommu=igfx_off option to workaround graphics issues
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_off option that is similar to Linux intel_iommu=igfx_off for users to manually workaround the problem. Signed-off-by: Ting-Wei Lan --- docs/misc/xen-command-line.markdown | 10 +- xen/drivers/passthrough/iommu.c | 3 +++ xen/drivers/passthrough/vtd/quirks.c | 2 +- xen/include/xen/iommu.h | 2 +- 4 files changed, 14 insertions(+), 3 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 13f03ad..7b61603 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 [ | force | required | intremap | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | verbose | debug ]` +> `= List of [ | force | required | intremap | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | igfx_off | verbose | debug ]` > Sub-options: @@ -867,6 +867,14 @@ debug hypervisor only). >> ignored (normally IOMMU setup fails if any of the devices listed by a DRHD >> entry aren't PCI discoverable). +> `igfx_off` (VT-d) + +> Default: `false` + +>> Workaround graphics issues for Intel Calpella/Ironlake devices. This option +>> is similar to Linux `intel_iommu=igfx_off`, so if it fixes anything, you +>> should file a bug reporting the problem. + > `verbose` > Default: `false` diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index cc12735..2ba8c9d 100644 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -47,6 +47,7 @@ bool_t __read_mostly force_iommu; bool_t __hwdom_initdata iommu_dom0_strict; bool_t __read_mostly iommu_verbose; bool_t __read_mostly iommu_workaround_bios_bug; +bool_t __read_mostly iommu_igfx_off; bool_t __read_mostly iommu_passthrough; bool_t __read_mostly iommu_snoop = 1; bool_t __read_mostly iommu_qinval = 1; @@ -87,6 +88,8 @@ static void __init parse_iommu_param(char *s) force_iommu = val; else if ( !strcmp(s, "workaround_bios_bug") ) iommu_workaround_bios_bug = val; +else if ( !strcmp(s, "igfx_off") ) +iommu_igfx_off = val; else if ( !strcmp(s, "verbose") ) iommu_verbose = val; else if ( !strcmp(s, "snoop") ) diff --git a/xen/drivers/passthrough/vtd/quirks.c b/xen/drivers/passthrough/vtd/quirks.c index 69d29ab..da1d853 100644 --- a/xen/drivers/passthrough/vtd/quirks.c +++ b/xen/drivers/passthrough/vtd/quirks.c @@ -77,7 +77,7 @@ int is_igd_vt_enabled_quirk(void) /* integrated graphics on Intel platforms is located at 0:2.0 */ ggc = pci_conf_read16(0, 0, IGD_DEV, 0, GGC); -return ( ggc & GGC_MEMORY_VT_ENABLED ? 1 : 0 ); +return ( ggc & GGC_MEMORY_VT_ENABLED ? 1 : 0 ) && !iommu_igfx_off; } /* diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h index 8eb764a..2cdb0a9 100644 --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -29,7 +29,7 @@ extern bool_t iommu_enable, iommu_enabled; extern bool_t force_iommu, iommu_verbose; -extern bool_t iommu_workaround_bios_bug, iommu_passthrough; +extern bool_t iommu_workaround_bios_bug, iommu_igfx_off, iommu_passthrough; extern bool_t iommu_snoop, iommu_qinval, iommu_intremap; extern bool_t iommu_hap_pt_share; extern bool_t iommu_debug; -- 2.4.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] VT-d: add iommu=igfx_off option to workaround graphics issues
於 一，2015-07-20 於 09:21 +0100，Andrew Cooper 提到： > On 20/07/2015 02:28, Tian, Kevin wrote: > > > From: Ting-Wei Lan [mailto:lant...@gmail.com] > > > Sent: Saturday, July 18, 2015 3:06 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_off option that is similar to Linux > > > intel_iommu=igfx_off for > > > users to manually workaround the problem. > > > > > > Signed-off-by: Ting-Wei Lan > > Since igfx works before, I'd think a more proper fix should be on > > the > > bisected Linux commit or i915 to have two working correctly > > together. > > Otherwise this patch is just hiding problem. > > The linux commit is the one which actually fixes PAT support for > Linux > under Xen. > > It will cause the i915 driver to actually get WC mappings when it > asks > for them. I made a new i915 bug report because the old one seems to be ignored: https://bugs.freedesktop.org/show_bug.cgi?id=91400 > > > There is one possible usage to do selective IOMMU disable other > > than > > global "iommu=off" switch. Then making this option general would > > be better than igfx_off, e.g. based on BDF. But I'm not sure how it > > is useful in reality. > > It is curious that just disabling the IOMMU appears to fix the > problem. Yes, disabling IOMMU (iommu=off or iommu=igfx_off added by this patch) avoids the problem. A similar problem also happens on Linux >= 3.7 without using Xen, and it can also be avoided using intel_iommu=igfx_off. > Are there any errata you are aware of on this class of system? With Xen: https://bugs.freedesktop.org/show_bug.cgi?id=90037 http://lists.xenproject.org/archives/html/xen-devel/2015 -06/msg02236.html https://bugs.freedesktop.org/show_bug.cgi?id=91400 Without Xen: https://bugs.freedesktop.org/show_bug.cgi?id=91127 > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] VT-d: add iommu=igfx_off option to workaround graphics issues
Jan Beulich 於 西元2015年07月21日 15:33 寫道: On 21.07.15 at 09:23, wrote: From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Tuesday, July 21, 2015 3:17 PM On 21.07.15 at 09:05, wrote: From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Tuesday, July 21, 2015 2:57 PM On 21.07.15 at 02:57, wrote: From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper Sent: Monday, July 20, 2015 4:21 PM This is the part which I don't quite understand. WC is essentially an UC attribute with write buffer to accelerate the write efficiency. There should be no correctness problem to use either WC or UC if i915 driver wants WC. "Should" is too weak a term here: Using WC on the wrong piece of memory or without the necessary fencing can imo very well cause correctness problems (which would be hidden by WC -> UC conversion behind the driver's back). My point is about when i915 wants WC, then either UC (I suppose is the case before that Linux commit) and WC (by that commit) has no correctness problem. UC is more strict than WC. It's just performance difference. It's not about using WC in wrong place when it's not desired. In this you assume there are no misguided attempts to request WC in the driver, which would have gone unnoticed as long as WC didn't become the effective attribute. And "misguided" here is meant to include cases where hardware errata may need taking care of. I don't understand this point. If it's misguided attempts it'd be same on bare metal. Not if bare metal has a workaround in place depending on (or even implemented in) IOMMU code. Also iirc the reported said that a similar problem existed (exists?) on native too. On 3.7 <= Linux < 4.2-rc2 without Xen, the screen output is broken, and the system crashes after display server is started. On Linux >= 4.2-rc2 without Xen, the screen output is normal because this patch is added https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8b572a4 but these messages are showed every a few seconds. If I keep using it, it will crash in about two hours. DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr fdf7 DMAR:[fault reason 05] PTE Write access is not set On Linux >= 3.19 with Xen, the screen output is broken, and these similar messages are showed. (XEN) [VT-D]DMAR:[DMA Write] Request device [:00:02.0] fault addr 73fbff000, iommu reg = 82c000203000 (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: use correct qemu path in systemd service file and init script
Ian Campbell 於 西元2015年07月21日 23:10 寫道: On Fri, 2015-07-17 at 00:15 +0800, Ting-Wei Lan wrote: This all looks pretty good. One comment: +if test "x$qemu_xen_path" = "x" || test "x$qemu_xen_path" = "xqemu"; then : + +qemu_xen_path_service="$LIBEXEC_BIN/qemu-system-i386" It's a shame we have to repeat the "qemu-system-i386" here and in libxl_dm.c. I think rather than adding a new qemu_xen_path_service we should just make the existing $qemu_xen_path default to the full $LIBEXEC_BIN/qemu -system-i386 and have it substituted everywhere much like you've done here. Then libxl_dm.c:qemu_xen_path() can return QEMU_XEN_PATH always. The help strings says: Use system supplied qemu PATH or qemu (taken from $PATH) as qemu-xen device model When $withval is yes, qemu_xen_path() returns "qemu" instead of a full path, so it cannot use QEMU_XEN_PATH because we are going to change it to a full path. Although qemu path in service file and init script is already broken if $withval is yes because we cannot know the full path of qemu when configuring, I think we still need to keep qemu_xen_path() working. What do you think? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: use correct qemu path in systemd service file and init script
Ian Campbell 於 西元2015年07月24日 16:57 寫道: On Fri, 2015-07-24 at 01:38 +0800, Ting-Wei Lan wrote: Ian Campbell 於 西元2015年07月21日 23:10 寫道: On Fri, 2015-07-17 at 00:15 +0800, Ting-Wei Lan wrote: This all looks pretty good. One comment: +if test "x$qemu_xen_path" = "x" || test "x$qemu_xen_path" = "xqemu"; then : + +qemu_xen_path_service="$LIBEXEC_BIN/qemu-system-i386" It's a shame we have to repeat the "qemu-system-i386" here and in libxl_dm.c. I think rather than adding a new qemu_xen_path_service we should just make the existing $qemu_xen_path default to the full $LIBEXEC_BIN/qemu -system-i386 and have it substituted everywhere much like you've done here. Then libxl_dm.c:qemu_xen_path() can return QEMU_XEN_PATH always. The help strings says: Use system supplied qemu PATH or qemu (taken from $PATH) as qemu-xen device model When $withval is yes, qemu_xen_path() returns "qemu" instead of a full path, so it cannot use QEMU_XEN_PATH because we are going to change it to a full path. I think if $withval is yes and we are converting that to "qemu" then QEMU_XEN_PATH should just be "qemu" and we should substitute that in the initscript too. IOW the "taken from $PATH" applies just as much to the initscript usage as it does to the toolstack. Yes, we can use "qemu" in init scripts, but systemd service files require absolute paths. We still have to do different things such as "/usr/bin/env qemu" for systemd. Ian. Although qemu path in service file and init script is already broken if $withval is yes because we cannot know the full path of qemu when configuring, I think we still need to keep qemu_xen_path() working. What do you think? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] VT-d: add iommu=igfx option to workaround graphics issues
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 --- 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 [ | force | required | intremap | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | verbose | debug ]` +> `= List of [ | 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. + > `verbose` > Default: `false` diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index cc12735..966cc66 100644 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -47,6 +47,7 @@ bool_t __read_mostly force_iommu; bool_t __hwdom_initdata iommu_dom0_strict; bool_t __read_mostly iommu_verbose; bool_t __read_mostly iommu_workaround_bios_bug; +bool_t __read_mostly iommu_igfx = 1; bool_t __read_mostly iommu_passthrough; bool_t __read_mostly iommu_snoop = 1; bool_t __read_mostly iommu_qinval = 1; @@ -87,6 +88,8 @@ static void __init parse_iommu_param(char *s) force_iommu = val; else if ( !strcmp(s, "workaround_bios_bug") ) iommu_workaround_bios_bug = val; +else if ( !strcmp(s, "igfx") ) +iommu_igfx = val; else if ( !strcmp(s, "verbose") ) iommu_verbose = val; else if ( !strcmp(s, "snoop") ) diff --git a/xen/drivers/passthrough/vtd/quirks.c b/xen/drivers/passthrough/vtd/quirks.c index 69d29ab..2eac1cf 100644 --- a/xen/drivers/passthrough/vtd/quirks.c +++ b/xen/drivers/passthrough/vtd/quirks.c @@ -77,7 +77,7 @@ int is_igd_vt_enabled_quirk(void) /* integrated graphics on Intel platforms is located at 0:2.0 */ ggc = pci_conf_read16(0, 0, IGD_DEV, 0, GGC); -return ( ggc & GGC_MEMORY_VT_ENABLED ? 1 : 0 ); +return ( ggc & GGC_MEMORY_VT_ENABLED ? 1 : 0 ) && iommu_igfx; } /* diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h index 8eb764a..29eed51 100644 --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -29,7 +29,7 @@ extern bool_t iommu_enable, iommu_enabled; extern bool_t force_iommu, iommu_verbose; -extern bool_t iommu_workaround_bios_bug, iommu_passthrough; +extern bool_t iommu_workaround_bios_bug, iommu_igfx, iommu_passthrough; extern bool_t iommu_snoop, iommu_qinval, iommu_intremap; extern bool_t iommu_hap_pt_share; extern bool_t iommu_debug; -- 2.4.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] build: use correct qemu path in systemd service file and init script
When --with-system-qemu is used, it is possible that we cannot find
qemu-system-i386 in LIBEXEC_BIN, which can cause error in xencommons
init script and xen-qemu-dom0-disk-backend.service systemd service.
Signed-off-by: Ting-Wei Lan
---
Changed since v1:
* Don't repeat qemu-system-i386 everywhere
* Use $qemu_xen_path in both init scripts and libxl_dm.c
* systemd requires executable path to be absolute so it is handled differently
tools/configure | 21 -
tools/configure.ac | 19 ++-
tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 2 +-
tools/hotplug/Linux/init.d/xencommons.in| 2 +-
.../systemd/xen-qemu-dom0-disk-backend.service.in | 2 +-
tools/libxl/libxl_dm.c | 4
6 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/tools/configure b/tools/configure
index 2fa7426..c0b3827 100755
--- a/tools/configure
+++ b/tools/configure
@@ -695,6 +695,8 @@ PREPEND_INCLUDES
EXTRA_QEMUU_CONFIGURE_ARGS
ovmf_path
seabios_path
+qemu_xen_systemd
+qemu_xen_path
qemu_xen
rombios
qemu_traditional
@@ -4142,9 +4144,14 @@ fi
if test "${with_system_qemu+set}" = set; then :
withval=$with_system_qemu;
case $withval in
-yes) qemu_xen=n ; qemu_xen_path=qemu ;;
-no) qemu_xen=y ; qemu_xen_path= ;;
-*) qemu_xen=n ; qemu_xen_path=$withval ;;
+yes)
+qemu_xen=n ; qemu_xen_path="qemu"
+qemu_xen_systemd="/usr/bin/env $qemu_xen_path" ;;
+no)
+qemu_xen=y ;;
+*)
+qemu_xen=n ; qemu_xen_path="$withval" ;
+qemu_xen_systemd="$qemu_xen_path" ;;
esac
else
@@ -4159,15 +4166,19 @@ else
fi
-if test "x$qemu_xen" = "xn"; then :
+if test "x$qemu_xen" = "xy"; then :
+
+qemu_xen_path="$LIBEXEC_BIN/qemu-system-i386"
+qemu_xen_systemd="$qemu_xen_path"
+fi
cat >>confdefs.h <<_ACEOF
#define QEMU_XEN_PATH "$qemu_xen_path"
_ACEOF
-fi
+
diff --git a/tools/configure.ac b/tools/configure.ac
index b7f1513..0209c6b 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -183,9 +183,14 @@ AC_ARG_WITH([system-qemu],
[Use system supplied qemu PATH or qemu (taken from $PATH) as qemu-xen
device model instead of building and installing our own version]),[
case $withval in
-yes) qemu_xen=n ; qemu_xen_path=qemu ;;
-no) qemu_xen=y ; qemu_xen_path= ;;
-*) qemu_xen=n ; qemu_xen_path=$withval ;;
+yes)
+qemu_xen=n ; qemu_xen_path="qemu"
+qemu_xen_systemd="/usr/bin/env $qemu_xen_path" ;;
+no)
+qemu_xen=y ;;
+*)
+qemu_xen=n ; qemu_xen_path="$withval" ;
+qemu_xen_systemd="$qemu_xen_path" ;;
esac
],[
case "$host_cpu" in
@@ -196,10 +201,14 @@ AC_ARG_WITH([system-qemu],
*) qemu_xen=n;;
esac
])
-AS_IF([test "x$qemu_xen" = "xn"], [
-AC_DEFINE_UNQUOTED([QEMU_XEN_PATH], ["$qemu_xen_path"], [Qemu Xen path])
+AS_IF([test "x$qemu_xen" = "xy"], [
+qemu_xen_path="$LIBEXEC_BIN/qemu-system-i386"
+qemu_xen_systemd="$qemu_xen_path"
])
+AC_DEFINE_UNQUOTED([QEMU_XEN_PATH], ["$qemu_xen_path"], [Qemu Xen path])
AC_SUBST(qemu_xen)
+AC_SUBST(qemu_xen_path)
+AC_SUBST(qemu_xen_systemd)
AC_ARG_WITH([system-seabios],
AS_HELP_STRING([--with-system-seabios@<:@=PATH@:>@],
diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index c12fc8a..78a2313 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -39,4 +39,4 @@
#XENBACKENDD_DEBUG=[yes|on|1]
# qemu path
-#QEMU_XEN=@LIBEXEC_BIN@/qemu-system-i386
+#QEMU_XEN=@qemu_xen_path@
diff --git a/tools/hotplug/Linux/init.d/xencommons.in
b/tools/hotplug/Linux/init.d/xencommons.in
index a1095c2..18cbf1c 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -98,7 +98,7 @@ do_start () {
test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS="
--log=$XENCONSOLED_TRACE"
${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
echo Starting QEMU as disk backend for dom0
- test -z "$QEMU_XEN" && QEMU_XEN="${LIBEXEC_BIN}/qemu-system-i386"
+ test -z "$QEMU_XEN" && QEMU_XEN="@qemu_xen_path@"
$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
-daemonize \
-monitor /dev/null -serial /dev/null -parallel /dev/null \
-pidfile $QEMU_PIDFILE
diff --git
Re: [Xen-devel] [PATCH v2] build: use correct qemu path in systemd service file and init script
於 四，2015-07-30 於 16:01 +0100，Ian Campbell 提到： > On Thu, 2015-07-30 at 11:30 +0100, Wei Liu wrote: > > On Thu, Jul 30, 2015 at 11:24:47AM +0100, Ian Campbell wrote: > > > On Thu, 2015-07-30 at 14:51 +0800, Ting-Wei Lan wrote: > > > > When --with-system-qemu is used, it is possible that we cannot find > > > > qemu-system-i386 in LIBEXEC_BIN, which can cause error in xencommons > > > > init script and xen-qemu-dom0-disk-backend.service systemd service. > > > > > > > > Signed-off-by: Ting-Wei Lan > > > > > > Personally I would have omitted the distinction between @qemu_xen_path@ > > > and > > > @qemu_xen_systemd@ and just put the env invocation in the service file > > > as > > > "/usr/bin/env @qemu_xen_path@" but I suppose that is just bike > > > shedding, > > > so: > > > > > > Acked-by: Ian Campbell > > > > > > Wei Lui, what do you think about this for 4.6? It fixes a real issue > > > where > > > --with-system-qemu is used without an explicit path, which is supposed > > > to > > > search for "qemu" in $PATH but fails to do so for the initscripts and > > > unit > > > files, where it uses the old hardcoded default value instead, which > > > probably doesn't exist if you are using this option (and if it did > > > isn't > > > the thing the user asked for). > > > > > > The fix looks pretty straight forward to me. > > > > > > > I agree with you. It should be applied for 4.6. > > Thanks, applied. > > Ting-Wei: I got a reject in xencommons.in because your tree apparently > lacks 8e986e5a61ef from May. Please check I've resolved it correctly, and > please use a more up to date baseline for future patches. Yes, the commit is correct. I forgot to test the patch on master branch before submitting it. My patch was made on stable-4.5 branch because this issue was found on Xen 4.5.1 release ... > > Thanks, > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] VT-d: add iommu=igfx option to workaround graphics issues
Tian, Kevin 於 西元2015年07月31日 09:26 寫道: From: Ting-Wei Lan [mailto:lant...@gmail.com] 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 --- 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 [ | force | required | intremap | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | verbose | debug ]` +> `= List of [ | 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; 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. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
