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. > >> Need help to understand what the use is of this? >> If it is some kind of USB debug device functionality using DMA on its >> MMIOs? Something else? >> I would like to understand this better what is going on here. > > USB controllers only do DMA to addresses that are given to them by > their driver. These addresses are obtained using the regular DMA > allocation routines (for example, dma_pool_create() or > dma_alloc_coherent() or dma_map_single()). They don't do DMA to > addresses in the MMIO region. > >> xen-devel related conversations: >> http://www.gossamer-threads.com/lists/xen/devel/363257 >> and >> http://www.gossamer-threads.com/lists/xen/devel/363355 >> >> Please let me know if more details needed. >> Thank you. >> >> >> >> 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. Elena > > 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
