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. > >> 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. 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/. Alan Stern -- 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
