On Thu, Jan 22, 2015 at 3:41 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 22 Jan 2015, Elena Ufimtseva wrote: > >> On Thu, Jan 22, 2015 at 1:10 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > On Thu, 22 Jan 2015, Elena Ufimtseva wrote: >> > >> >> Hello >> >> >> >> While working on IOMMU related problem for Xen Hypervisor, >> >> it was discovered that on some machines IOMMU page faults are triggered >> >> on certain addresses and requests that cause this are DMA requests >> >> with source device >> >> identified as USB Host controllers. >> > >> >> Thank you for taking a look at this Alan. >> >> > You mean EHCI controllers? >> >> Right, EHCI controllers. >> >> > >> >> Further analysis showed that faulting addresses are not mapped with IOMMU with >> >> RW as these regions are not enumerated as RMRRs. >> >> Xen does make sure that RMRRs are mapped RW in IOMMU. >> >> These faulting addresses fall into reserved region within e820 map. >> > >> > Are you saying that the addresses aren't mapped at all, or that they >> > are mapped RO rather than RW? >> >> These are not mapped. They dont have EPTs only because in code there is >> a condition missing. RMRRs enumerated by ACPI RMRRs are mapped with RW access. >> I think this lead to a question being discussed on xen-devel on why >> there is a device >> that would initiate DMA request on reserved and not rmrr marked region. > > I don't know what "EPT" and "RMRR" mean. RMRR is ACPI Reserved memory Region Reporting Structure reported for iommu unit. EPT - extended page tables in Intel VT-x. > >> >> This page faults with addresses/devices are being logged under Xen: >> >> >> >> (XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs >> >> (XEN) IOMMU Page fault! >> >> (XEN) IOMMU Page fault! >> >> (XEN) [VT-D]iommu.c:875: iommu_fault_status: Fault Overflow >> >> (XEN) [VT-D]iommu.c:877: iommu_fault_status: Primary Pending Fault >> >> (XEN) [VT-D]iommu.c:855: DMAR:[DMA Read] Request device [0000:00:1a.0] >> >> fault addr d5d46000, iommu reg = ffff82c000203000 >> > >> > Why do you think d6d46000 is in the MMIO region for the 0000:00:1a.0 >> > device? According to the log: >> > >> >> [ 13.340574] ehci-pci 0000:00:1a.0: irq 17, io mem 0xf7c38000 >> > >> > So the MMIO region starts at f7c38000. >> >> Right, I agree and I saw it. Its not MMIO, rather its assumed that if its not >> RAM in e820 map, that it may be MMIO. I probably should not use this term. >> In this case faulting addresses do not match any of MMIOs reported per device >> or RMRRs. >> At the same time the identified devices do initiate DMA reads for the >> addresses mentioned. >> I just wanted to see what it can be and understand the better way to solve it. > > If that address isn't mapped to RAM then there's no reason for the EHCI > controller to issue a DMA using the address. Understood. > > On the other hand, it's not easy to find all the DMA addresses that an > EHCI controller uses. There are a few coherent DMA pools, some static > coherent mappings, and some dynamic streaming mappings. > > One place to start looking is in the files under > /sys/kernel/debug/usb/ehci/0000:00:1a.0/. Thank you Alan, I will look into this. > > Alan Stern > -- Elena -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
