Re: RFC on No ACS Support and SMMUv3 Support

[Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>]

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