* iommu=no-igfx
@ 2020-05-11 17:43 buy computer
2020-05-20 11:10 ` iommu=no-igfx Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: buy computer @ 2020-05-11 17:43 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 716 bytes --]
Hi!
I've been working on a Windows 10 HVM on a Debian 10 dom0. When I was first
trying to make the VM, I was getting IOMMU errors. I had a hard time
figuring out what to do about this, and finally discovered that putting
iommu=no-igfx in the grub stopped the errors.
Unfortunately, without the graphics support the VM is understandably slow,
and can crash. I was also only now pointed to the page
<https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#iommu>
which says to report any errors that get fixed by using iommu=no-igfx.
I'm attaching a copy of xl dmesg from before I put in the no-igfx. The
bottom is the iommu errors. If there is a better way for me to share the
output, please let me know.
[-- Attachment #1.2: Type: text/html, Size: 850 bytes --]
[-- Attachment #2: xendmesg.log --]
[-- Type: text/x-log, Size: 11575 bytes --]
(XEN) parameter "placeholder" unknown!
(XEN) parameter "no-real-mode" unknown!
(XEN) parameter "edd" unknown!
(XEN) Xen version 4.11.4-pre (Debian 4.11.3+24-g14b62ab3e5-1~deb10u1) (pkg-xen-devel@lists.alioth.debian.org) (gcc (Debian 8.3.0-6) 8.3.0) debug=n Wed Jan 8 20:16:51 UTC 2020
(XEN) Bootloader: GRUB 2.02+dfsg1-20
(XEN) Command line: placeholder no-real-mode edd=off
(XEN) Xen image load base address: 0x7be00000
(XEN) Video information:
(XEN) VGA is graphics mode 1920x1080, 32 bpp
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN) 0000000000000000 - 000000000009f000 (usable)
(XEN) 000000000009f000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000007ccba000 (usable)
(XEN) 000000007ccba000 - 000000007fbe7000 (reserved)
(XEN) 000000007fbe7000 - 000000007fcaa000 (ACPI NVS)
(XEN) 000000007fcaa000 - 000000007fd0f000 (ACPI data)
(XEN) 000000007fd0f000 - 000000007fd10000 (usable)
(XEN) 000000007fd10000 - 0000000088000000 (reserved)
(XEN) 0000000088000000 - 0000000088200000 (usable)
(XEN) 0000000088200000 - 000000008c800000 (reserved)
(XEN) 00000000fe010000 - 00000000fe011000 (reserved)
(XEN) 0000000100000000 - 0000000871800000 (usable)
(XEN) ACPI: RSDP 7FD0E014, 0024 (r2 LENOVO)
(XEN) ACPI: XSDT 7FD0C188, 010C (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: FACP 7E9E6000, 0114 (r6 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: DSDT 7E9BE000, 2311B (r2 LENOVO CFL 20170001 INTL 20160422)
(XEN) ACPI: FACS 7FC05000, 0040
(XEN) ACPI: SSDT 7EA93000, 1B1C (r2 LENOVO CpuSsdt 3000 INTL 20160527)
(XEN) ACPI: SSDT 7EA92000, 056D (r2 LENOVO CtdpB 1000 INTL 20160527)
(XEN) ACPI: SSDT 7EA59000, 3996 (r2 LENOVO DptfTabl 1000 INTL 20160527)
(XEN) ACPI: SSDT 7E9EB000, 313D (r2 LENOVO SaSsdt 3000 INTL 20160527)
(XEN) ACPI: SSDT 7E9EA000, 0612 (r2 LENOVO Tpm2Tabl 1000 INTL 20160527)
(XEN) ACPI: TPM2 7E9E9000, 0034 (r4 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: UEFI 7FC1A000, 0042 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: SSDT 7E9E7000, 0538 (r2 LENOVO PerfTune 1000 INTL 20160527)
(XEN) ACPI: HPET 7E9E5000, 0038 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: APIC 7E9E4000, 012C (r3 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: MCFG 7E9E3000, 003C (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: ECDT 7E9E2000, 0053 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: SSDT 7E9BB000, 2304 (r2 LENOVO ProjSsdt 10 INTL 20160527)
(XEN) ACPI: BOOT 7E9BA000, 0028 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: SLIC 7E9B9000, 0176 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: SSDT 7E9B8000, 0CE3 (r2 LENOVO UsbCTabl 1000 INTL 20160527)
(XEN) ACPI: LPIT 7E9B7000, 005C (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: WSMT 7E9B6000, 0028 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: SSDT 7E9B4000, 149F (r2 LENOVO TbtTypeC 0 INTL 20160527)
(XEN) ACPI: DBGP 7E9B3000, 0034 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: DBG2 7E9B2000, 0054 (r0 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: MSDM 7E9B1000, 0055 (r3 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: BATB 7E99C000, 004A (r2 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: NHLT 7DB99000, 002D (r0 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: DMAR 7DB98000, 00A8 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: FPDT 7DB96000, 0044 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: BGRT 7DB95000, 0038 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) ACPI: UEFI 7FC00000, 0116 (r1 LENOVO TP-R0Y 1B0 PTEC 2)
(XEN) System RAM: 32486MB (33266024kB)
(XEN) Domain heap initialised
(XEN) ACPI: Invalid sleep control/status register data: 0:0x8:0x3 0:0x8:0x3
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 7fc05000/0000000000000000, using 32
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-119
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) Switched to APIC driver x2apic_cluster
(XEN) xstate: size: 0x440 and states: 0x1f
(XEN) Speculative mitigation facilities:
(XEN) Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD RDCL_NO SKIP_L1DFL
(XEN) Compiled-in support: INDIRECT_THUNK SHADOW_PAGING
(XEN) Xen settings: BTI-Thunk JMP, SPEC_CTRL: IBRS+ SSBD-, Other: IBPB
(XEN) Support for VMs: PV: MSR_SPEC_CTRL RSB EAGER_FPU, HVM: MSR_SPEC_CTRL RSB EAGER_FPU
(XEN) XPTI (64-bit PV only): Dom0 disabled, DomU disabled
(XEN) PV L1TF shadowing: Dom0 disabled, DomU disabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Platform timer is 23.999MHz HPET
(XEN) Detected 1992.103 MHz processor.
(XEN) Initing memory sharing.
(XEN) PCI: Not using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Posted Interrupt not enabled.
(XEN) Intel VT-d Shared EPT tables enabled.
(XEN) I/O virtualisation enabled
(XEN) - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using old ACK method
(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Extended Page Tables (EPT)
(XEN) - Virtual-Processor Identifiers (VPID)
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) - Unrestricted Guest
(XEN) - VM Functions
(XEN) - Virtualisation Exceptions
(XEN) - Page Modification Logging
(XEN) HVM: ASIDs enabled.
(XEN) VMX: Disabling executable EPT superpages due to CVE-2018-12207
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 8 CPUs
(XEN) Dom0 has maximum 888 PIRQs
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x282c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000850000000->0000000854000000 (8147267 pages to be allocated)
(XEN) Init. ramdisk: 000000086f254000->00000008717ffd6c
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff8282c000
(XEN) Init. ramdisk: 0000000000000000->0000000000000000
(XEN) Phys-Mach map: 0000008000000000->0000008003e5b778
(XEN) Start info: ffffffff8282c000->ffffffff8282c4b8
(XEN) Xenstore ring: 0000000000000000->0000000000000000
(XEN) Console ring: 0000000000000000->0000000000000000
(XEN) Page tables: ffffffff8282d000->ffffffff82846000
(XEN) Boot stack: ffffffff82846000->ffffffff82847000
(XEN) TOTAL: ffffffff80000000->ffffffff82c00000
(XEN) ENTRY ADDRESS: ffffffff82456180
(XEN) Dom0 has maximum 8 VCPUs
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) ....................................................................done.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) ***************************************************
(XEN) Booted on MLPDS/MFBDS-vulnerable hardware with SMT/Hyperthreading
(XEN) enabled. Mitigations will not be fully effective. Please
(XEN) choose an explicit smt=<bool> setting. See XSA-297.
(XEN) ***************************************************
(XEN) 3... 2... 1...
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 476kB init memory
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 76c615d000, iommu reg = ffff82c000a0c000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 76c615d000, iommu reg = ffff82c000a0c000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 76c615d000, iommu reg = ffff82c000a0c000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 76c615d000, iommu reg = ffff82c000a0c000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 76c615d000, iommu reg = ffff82c000a0c000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) printk: 200 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 76c615d000, iommu reg = ffff82c000a0c000
(XEN) printk: 145 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 212ed69000, iommu reg = ffff82c000a0c000
(XEN) printk: 501 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 212ed69000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 212ed69000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 1f27d91000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 4f6eea4000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 7470ecb000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 4f6eea4000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 4f6eea4000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 4f6eea4000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 7470ecb000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 7470ecb000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 7470ecb000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 7470ecb000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 1f27d91000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 4f6eea4000, iommu reg = ffff82c000a0c000
(XEN) printk: 601 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 1f27d91000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 7470ecb000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 7470ecb000, iommu reg = ffff82c000a0c000
(XEN) printk: 599 messages suppressed.
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 1f27d91000, iommu reg = ffff82c000a0c000
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iommu=no-igfx
2020-05-11 17:43 iommu=no-igfx buy computer
@ 2020-05-20 11:10 ` Jan Beulich
2020-05-25 2:15 ` iommu=no-igfx Tian, Kevin
0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2020-05-20 11:10 UTC (permalink / raw)
To: buy computer; +Cc: xen-devel, Kevin Tian
On 11.05.2020 19:43, buy computer wrote:
> I've been working on a Windows 10 HVM on a Debian 10 dom0. When I was first
> trying to make the VM, I was getting IOMMU errors. I had a hard time
> figuring out what to do about this, and finally discovered that putting
> iommu=no-igfx in the grub stopped the errors.
>
> Unfortunately, without the graphics support the VM is understandably slow,
> and can crash. I was also only now pointed to the page
> <https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#iommu>
> which says to report any errors that get fixed by using iommu=no-igfx.
Thanks for the report. For context I'll quote the commit message of
the commit introducing the option as well as the request to report
issues fixed with it:
"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."
This was in 2015, referencing Linux >= 3.19. I have no idea whether
the underlying driver issue(s) has/have been fixed. The addresses
referenced are variable enough and all within RAM, so I'd conclude
this is not a "missing RMRR" issue.
Cc-ing the VT-d maintainer for possible insights or thoughts.
Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: iommu=no-igfx
2020-05-20 11:10 ` iommu=no-igfx Jan Beulich
@ 2020-05-25 2:15 ` Tian, Kevin
2020-05-25 5:17 ` iommu=no-igfx buy computer
0 siblings, 1 reply; 6+ messages in thread
From: Tian, Kevin @ 2020-05-25 2:15 UTC (permalink / raw)
To: Jan Beulich, buy computer; +Cc: xen-devel
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, May 20, 2020 7:11 PM
>
> On 11.05.2020 19:43, buy computer wrote:
> > I've been working on a Windows 10 HVM on a Debian 10 dom0. When I
> was first
> > trying to make the VM, I was getting IOMMU errors. I had a hard time
> > figuring out what to do about this, and finally discovered that putting
> > iommu=no-igfx in the grub stopped the errors.
> >
> > Unfortunately, without the graphics support the VM is understandably
> slow,
> > and can crash. I was also only now pointed to the page
> > <https://xenbits.xen.org/docs/unstable/misc/xen-command-
> line.html#iommu>
> > which says to report any errors that get fixed by using iommu=no-igfx.
what is the platform and linux kernel version in this context?
>
> Thanks for the report. For context I'll quote the commit message of
> the commit introducing the option as well as the request to report
> issues fixed with it:
>
> "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."
>
> This was in 2015, referencing Linux >= 3.19. I have no idea whether
> the underlying driver issue(s) has/have been fixed. The addresses
> referenced are variable enough and all within RAM, so I'd conclude
> this is not a "missing RMRR" issue.
Variable enough but not within RAM. From E820:
(XEN) 0000000100000000 - 0000000871800000 (usable)
But the referenced addresses are way higher:
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault
addr 76c615d000, iommu reg = ffff82c000a0c000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
>
> Cc-ing the VT-d maintainer for possible insights or thoughts.
>
> Jan
I don't have other thoughts except the weird addresses. It might be
good to add some trace in dom0's i915 driver to see whether those
addresses are intended or not.
Thanks
Kevin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iommu=no-igfx
2020-05-25 2:15 ` iommu=no-igfx Tian, Kevin
@ 2020-05-25 5:17 ` buy computer
2020-05-28 8:34 ` iommu=no-igfx Tian, Kevin
0 siblings, 1 reply; 6+ messages in thread
From: buy computer @ 2020-05-25 5:17 UTC (permalink / raw)
To: Tian, Kevin, xen-devel
[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]
On Mon, May 25, 2020 at 5:16 AM Tian, Kevin <kevin.tian@intel.com> wrote:
> > From: Jan Beulich <jbeulich@suse.com>
> > Sent: Wednesday, May 20, 2020 7:11 PM
> >
> > On 11.05.2020 19:43, buy computer wrote:
> > > I've been working on a Windows 10 HVM on a Debian 10 dom0. When I
> > was first
> > > trying to make the VM, I was getting IOMMU errors. I had a hard time
> > > figuring out what to do about this, and finally discovered that putting
> > > iommu=no-igfx in the grub stopped the errors.
> > >
> > > Unfortunately, without the graphics support the VM is understandably
> > slow,
> > > and can crash. I was also only now pointed to the page
> > > <https://xenbits.xen.org/docs/unstable/misc/xen-command-
> > line.html#iommu>
> > > which says to report any errors that get fixed by using iommu=no-igfx.
>
> what is the platform and linux kernel version in this context?
>
>
I'm not sure what you meant by 'platform', so I'll try to cover all the
bases.
Kernel: 4.19.0-9-amd64 GNU/Linux
Debian 10.4
Lenovo E490 ThinkPad
Intel Integrated Graphics 620
> >
> > Thanks for the report. For context I'll quote the commit message of
> > the commit introducing the option as well as the request to report
> > issues fixed with it:
> >
> > "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."
> >
> > This was in 2015, referencing Linux >= 3.19. I have no idea whether
> > the underlying driver issue(s) has/have been fixed. The addresses
> > referenced are variable enough and all within RAM, so I'd conclude
> > this is not a "missing RMRR" issue.
>
> Variable enough but not within RAM. From E820:
>
> (XEN) 0000000100000000 - 0000000871800000 (usable)
>
> But the referenced addresses are way higher:
>
> (XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault
> addr 76c615d000, iommu reg = ffff82c000a0c000
> (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
>
> >
> > Cc-ing the VT-d maintainer for possible insights or thoughts.
> >
> > Jan
>
> I don't have other thoughts except the weird addresses. It might be
> good to add some trace in dom0's i915 driver to see whether those
> addresses are intended or not.
>
>
Thanks for the insight! I'd love to help with the trace, but I don't know
how to do that. If you could point me in the right direction, I'd try to
give it a shot.
Thanks
> Kevin
>
Thanks for the insight!
[-- Attachment #2: Type: text/html, Size: 4005 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: iommu=no-igfx
2020-05-25 5:17 ` iommu=no-igfx buy computer
@ 2020-05-28 8:34 ` Tian, Kevin
2020-06-01 12:20 ` iommu=no-igfx buy computer
0 siblings, 1 reply; 6+ messages in thread
From: Tian, Kevin @ 2020-05-28 8:34 UTC (permalink / raw)
To: buy computer, xen-devel
[-- Attachment #1: Type: text/plain, Size: 3103 bytes --]
You may search dma_map* in drivers/gpu/drm/i915, and then print mapped addresses to see any match in VT-d reported faulting addresses. For example, __setup_page_dma might be one example that you want to check.
From: buy computer <buycomputer40@gmail.com>
Sent: Monday, May 25, 2020 1:18 PM
To: Tian, Kevin <kevin.tian@intel.com>; xen-devel@lists.xenproject.org
Subject: Re: iommu=no-igfx
On Mon, May 25, 2020 at 5:16 AM Tian, Kevin <kevin.tian@intel.com<mailto:kevin.tian@intel.com>> wrote:
> From: Jan Beulich <jbeulich@suse.com<mailto:jbeulich@suse.com>>
> Sent: Wednesday, May 20, 2020 7:11 PM
>
> On 11.05.2020 19:43, buy computer wrote:
> > I've been working on a Windows 10 HVM on a Debian 10 dom0. When I
> was first
> > trying to make the VM, I was getting IOMMU errors. I had a hard time
> > figuring out what to do about this, and finally discovered that putting
> > iommu=no-igfx in the grub stopped the errors.
> >
> > Unfortunately, without the graphics support the VM is understandably
> slow,
> > and can crash. I was also only now pointed to the page
> > <https://xenbits.xen.org/docs/unstable/misc/xen-command-
> line.html#iommu>
> > which says to report any errors that get fixed by using iommu=no-igfx.
what is the platform and linux kernel version in this context?
I'm not sure what you meant by 'platform', so I'll try to cover all the bases.
Kernel: 4.19.0-9-amd64 GNU/Linux
Debian 10.4
Lenovo E490 ThinkPad
Intel Integrated Graphics 620
>
> Thanks for the report. For context I'll quote the commit message of
> the commit introducing the option as well as the request to report
> issues fixed with it:
>
> "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."
>
> This was in 2015, referencing Linux >= 3.19. I have no idea whether
> the underlying driver issue(s) has/have been fixed. The addresses
> referenced are variable enough and all within RAM, so I'd conclude
> this is not a "missing RMRR" issue.
Variable enough but not within RAM. From E820:
(XEN) 0000000100000000 - 0000000871800000 (usable)
But the referenced addresses are way higher:
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault
addr 76c615d000, iommu reg = ffff82c000a0c000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
>
> Cc-ing the VT-d maintainer for possible insights or thoughts.
>
> Jan
I don't have other thoughts except the weird addresses. It might be
good to add some trace in dom0's i915 driver to see whether those
addresses are intended or not.
Thanks for the insight! I'd love to help with the trace, but I don't know how to do that. If you could point me in the right direction, I'd try to give it a shot.
Thanks
Kevin
Thanks for the insight!
[-- Attachment #2: Type: text/html, Size: 7463 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iommu=no-igfx
2020-05-28 8:34 ` iommu=no-igfx Tian, Kevin
@ 2020-06-01 12:20 ` buy computer
0 siblings, 0 replies; 6+ messages in thread
From: buy computer @ 2020-06-01 12:20 UTC (permalink / raw)
To: Tian, Kevin; +Cc: xen-devel
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
On Thu, May 28, 2020 at 11:34 AM Tian, Kevin <kevin.tian@intel.com> wrote:
> You may search dma_map* in drivers/gpu/drm/i915, and then print mapped
> addresses to see any match in VT-d reported faulting addresses. For
> example, __setup_page_dma might be one example that you want to check.
>
Unfortunately, I'm not really clear on how to do that too. I've found
drivers/gpu/drm/i915, and it contains one file, i915.ko. Using cat prints
out unformatted text. How do I access this data? Internet searches have
again come up dry for me, sorry if this question isn't on the level.
[-- Attachment #2: Type: text/html, Size: 1058 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-01 12:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-11 17:43 iommu=no-igfx buy computer
2020-05-20 11:10 ` iommu=no-igfx Jan Beulich
2020-05-25 2:15 ` iommu=no-igfx Tian, Kevin
2020-05-25 5:17 ` iommu=no-igfx buy computer
2020-05-28 8:34 ` iommu=no-igfx Tian, Kevin
2020-06-01 12:20 ` iommu=no-igfx buy computer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).