On 3/13/2018 12:43 PM, Logan Gunthorpe wrote: > > > On 12/03/18 09:28 PM, Sinan Kaya wrote: >> On 3/12/2018 3:35 PM, Logan Gunthorpe wrote: >> Regarding the switch business, It is amazing how much trouble you went into >> limit this functionality into very specific hardware. >> >> I thought that we reached to an agreement that code would not impose >> any limits on what user wants. >> >> What happened to all the emails we exchanged? > > It turns out that root ports that support P2P are far less common than anyone > thought. So it will likely have to be a white list. Nobody else seems keen on > allowing the user to enable this on hardware that doesn't work. The easiest > solution is still limiting it to using a switch. From there, if someone wants > to start creating a white-list then that's probably the way forward to > support root ports.
I thought only few root ports had problem. Thanks for clarifying that. > > And there's also the ACS problem which means if you want to use P2P on the > root ports you'll have to disable ACS on the entire system. (Or preferably, > the IOMMU groups need to get more sophisticated to allow for dynamic changes). > Do you think you can keep a pointer to the parent bridge instead of querying it via get_upstream_bridge_port() here so that we can reuse your pci_p2pdma_disable_acs() in the future. +int pci_p2pdma_disable_acs(struct pci_dev *pdev) +{ + struct pci_dev *up; + int pos; + u16 ctrl; + + up = get_upstream_bridge_port(pdev); + if (!up) + return 0; Some future device would only deal with pci_p2pdma_add_client(() for whitelisting instead of changing all of your code. We should at least limit the usage of get_upstream_bridge_port() family of functions to probe time only. > Additionally, once you allow for root ports you may find the IOMMU getting in > the way. We can tell iommu to do one to one translation by passing iommu.passthrough=1 to kernel command line to have identical behavior to your switch case. > > So there are great deal more issues to sort out if you don't restrict to > devices behind switches. > > Logan > -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm