On Wed, 2011-06-15 at 15:51 -0700, Bjorn Helgaas wrote: > On Wed, Jun 15, 2011 at 3:30 PM, Benjamin Herrenschmidt > <benh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2011-06-15 at 17:23 -0500, Jon Mason wrote: > >> I could add the simpler way of doing it as an alternative and have a > >> kernel boot parameter to switch between the two. For PPC, the kernel > >> parameter could default to always use the alternative way of doing it. > >> Would this be acceptable? > > > > That would work for me. > > What are the failure modes here? I think the proposal is to have two modes: > > 1) clamp MPS aggressively to (minimum MPS of all devices in the system), or > 2) clamp MPS to the minimum of (device MPS, upstream bridge MPS). > > The first mode should be safe and allow peer-to-peer DMA transfers. > The second (if I understand correctly) is unsafe in that peer-to-peer > transfers may cause bus errors. > > Do we have any clue about whether drivers are attempting peer-to-peer > DMA? It would be kind of mysterious to users if a new driver or new > way of using a device made the system unstable. Generic drivers don't and our dma APIs don't really allow for this. AFAIK. To do that reliably drivers would have to find the "bus" address of the peer device, using pcibios_resource_to_bus or similar which I don't think any driver does. So I suspect this exist only in embedded applications that we haven't seen upstream.... but I might be missing something. > It'd be nice if there were some way to tell the user that "PCI > hierarchy under X is configured for speed, but is unsafe for > peer-to-peer." Or maybe this just something we debug if/when > peer-to-peer failures occur. Well, if we ever want to officially support peer-to-peer, maybe we should provide APIs for that. The MPS could then be reconfigured, it really only needs to be clamped down in that case on the path between the devices and we can put the requirement on drivers to only do that when they are "idle". Or we can just fail if the requirement isn't met. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
