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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Mar 04, 2025 at 10:16:45AM +0800, Baolu Lu wrote:
> For ATS enablement, I believe we have already reached some agreement
> that ATS enablement is in an on-demand manner. ATS is enabled when the
> first domain that requires ATS is attached and disabled when the last
> domain is detached. That matches what we are doing for PRI.

It is not quite so simple, we need ATS in some virtualization cases
for VFIO even though it is not "using" ATS for PRI.

Today the iommu drivers always enable ATS for paging domains if ATS is
supported. This is what I'm wondering if it should be made optional

> When a domain attachment triggers ATS to be on, there might be some
> cases:
> 
> - ATS does not impact functionality. For example, ATS could be enabled
>   for the DMA domain for better performance. In this case, it's a
>   successful case if the device supports ATS but the platform can't
>   provide the secure ATS that is demanded by the user's ATS security
>   level. ATS will not be enabled but attach returns success.
> 
> - ATS impacts functionality. For example, the domain requires PRI. In
>   this case, it's a failure case when the device does not support ATS or
>   the ATS security is insufficient.
> 
> - ATS compatibility should also be checked in domain attach path. If ATS
>   policy between attaching domain and the device does not match, an
>   -EINVAL should be returned to inform the caller that "domain is not
>   compatible, suggest to allocate a dedicated domain for this device".

But this philosophy makes sense

Jason