On 2/14/2017 7:36 AM, Will Deacon wrote: > 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 > Thanks to everyone for feedback. I'll follow the quirk path as requested. I'll be posting the patch soon. -- 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.
