On 10 July 2017 at 18:21, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > On 10 July 2017 at 16:52, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> Ard and myself have just spent quite some time lately trying to pin >> down an issue in the DMA code which was taking the form of a PCIe USB3 >> controller issuing a DMA access at some bizarre address, and being >> caught red-handed by the IOMMU. >> >> After much head scratching and most of a week-end spent on tracing the >> damn thing, I'm now convinced that the DMA code is fine, the XHCI >> driver is correct, but that the HW (a Renesas uPD720202 chip) is a >> nasty piece of work. >> >> The issue is as follow: >> >> - EFI initializes the controller using physical addresses above the >> 4GB limit (this is on an arm64 box where the memory starts at >> 0x80_00000000...). >> >> - The kernel takes over, sends a XHCI reset to the controller, and >> because we have an IOMMU sitting between the controller and memory, >> provides *virtual* addresses. Trying to make things a bit faster for >> our controller, it issues IOVAs in the low 4GB range). >> >> - Low and behold, the controller is now issuing transactions with a >> 0x80 prefix in front of our IOVA. Yes, the same prefix that was >> programmed during the EFI configuration. IOMMU fault, not happy. >> >> If the kernel is hacked to only generate IOVAs that are more than >> 32bit wide, the HW behaves correctly. The only way I can explain this >> behaviour is that the HW latches the top 32bit of the ERST (it is >> always the ERST IOVA that appears in my traces) in some internal >> register, and that the XHCI reset fails to clear it. Writing zero in >> the top bits is not enough to clear it either. >> > > To clarify, this seems to be an issue in the internal DMA logic of the > controller. The ESRT base address register *is* cleared by the XHCI > reset, i.e., it reads back as all zeroes. However, any 32-bit value we > write there is extended with the high word written by the UEFI in the > actual DMA transactions that take place. > >> So far, the only solution we have for this lovely piece of kit is to >> force a PCI reset at probe time, which puts it right. The patches are >> pretty ugly, but that's the best I could come up with so far. >> >> Tested on a pair of AMD Opteron 1100 boxes with Renesas uPD720201 and >> uPD720202 controllers. >> >> Marc Zyngier (2): >> PCI: Implement pci_reset_function_locked >> usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB >> controller >> Tested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> -- 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
