On 08/05/18 05:00 PM, Dan Williams wrote: >> I'd advise caution with a user supplied BDF approach, we have no >> guaranteed persistence for a device's PCI address. Adding a device >> might renumber the buses, replacing a device with one that consumes >> more/less bus numbers can renumber the buses, motherboard firmware >> updates could renumber the buses, pci=assign-buses can renumber the >> buses, etc. This is why the VT-d spec makes use of device paths when >> describing PCI hierarchies, firmware can't know what bus number will be >> assigned to a device, but it does know the base bus number and the path >> of devfns needed to get to it. I don't know how we come up with an >> option that's easy enough for a user to understand, but reasonably >> robust against hardware changes. Thanks, > > True, but at the same time this feature is for "users with custom > hardware designed for purpose", I assume they would be willing to take > on the bus renumbering risk. It's already the case that > /sys/bus/pci/drivers/<x>/bind takes BDF, which is why it seemed to > make a similar interface for the command line. Ideally we could later > get something into ACPI or other platform firmware to arrange for > bridges to disable ACS by default if we see p2p becoming a > common-off-the-shelf feature. I.e. a BIOS switch to enable p2p in a > given PCI-E sub-domain. Yeah, I'm having a hard time coming up with an easy enough solution for the user. I agree with Dan though, the bus renumbering risk would be fairly low in the custom hardware seeing the switches are likely going to be directly soldered to the same board with the CPU. That being said, I supposed we could allow the command line to take both a BDF or a BaseBus/DF/DF/DF path. Though, implementing this sounds like a bit of a challenge. Logan
