Re: [PATCH] iommu/amd: Add Secure ATS support

[Yi Liu <yi.l.liu@intel.com>]

On 2025/3/4 02:38, Jason Gunthorpe wrote:
> On Sun, Mar 02, 2025 at 04:10:46PM +0800, Yi Liu wrote:
>> I'm also thinking about the impact of such a knob. How should we define
>> this knob. Should we allow it to disable/enable ATS? Especially in runtime.
>> e.g. if the device is identified to be ATS untrusted by the admin, while
>> the hw does not support SATS, it seems reasonable to disable ATS for
>> such device. This might change the driver behavior on ATS enabling. Intel
>> iommu driver enables ATS as long as it's available in the probe_device()
>> op. What about AMD and ARM?

sorry, a revise. Existing intel iommu driver enables ATS in the time of
domain attach. While Baolu has the below series [1] to move it to
probe_device().

[1] 
https://lore.kernel.org/linux-iommu/20250224051627.2956304-5-baolu.lu@linux.intel.com/

> ARM enables ATS when a PAGING translation is set on the RID or any
> PASID is used. Otherwise it is off, eg for RID = IDENTITY
> 
> This seems like a reasonable thing to do to me..

will it affect Baolu's above refactoring [1]? :(

>> On the other hand, we may just define the knob as sats required or not.
>> This is just a knob to let kernel know if the iommu driver needs to enable
>> sats or not. While leave the ATS enabling policy unchanged. This means
>> we need to probe the sats capability of iommu hw before creating the knob
>> in sysfs.
> 
> If we add some ATS control knob then maybe it should be able to
> disable/enable normal ATS as well?
> 
>   never
>   always
>   paging-only

this can be considered policy to the existing ATS. curious, why paging
domain is special here?

>   secure-always
>   secure-paging-only

and this is the policy of secure ATS.

A general question. Can admin op the knob if the device has been attached
to any domain?

-- 
Regards,
Yi Liu