On Mon, Feb 13, 2017 at 08:54:04PM -0500, Sinan Kaya wrote: > On 2/13/2017 8:46 PM, Alex Williamson wrote: > >> My first goal is to support virtual function passthrough for device's that are directly > >> connected. This will be possible with the quirk I proposed and it will be the most > >> secure solution. It can certainly be generalized for other systems. > > Why is this anything more than a quirk for the affected PCIe root port > > vendor:device IDs and use of pci_device_group() to evaluate the rest of > > the topology, as appears is already done? Clearly a blanket exception > > for the platform wouldn't necessarily be correct if a user could plugin > > a device that adds a PCIe switch. > > I was going to go this direction first. I wanted to check with everybody to see > if there are other/better alternatives possible via either changing > pci_device_group or changing the smmuv3 driver. Just to echo what Alex has been saying, I really don't think we should support this type of system by quirking the topology code in the SMMU driver. The SMMU isn't at fault here; the problems are all upstream of that. Legitimising non-ACS machines in the SMMU driver gives little incentive for people to build systems correctly and undermines the security guarantees that the SMMU (and VFIO) are trying to provide. I appreciate that I/O virtualisation on arm64 has been a learning curve for everybody involved, but that's not an excuse for moving the goalposts when it comes to device isolation. Will
