Re: RFC on No ACS Support and SMMUv3 Support

[Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]

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.