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

[Vasant Hegde <vasant.hegde@amd.com>]

Jason,


On 3/4/2025 7:54 PM, Jason Gunthorpe wrote:
> On Tue, Mar 04, 2025 at 03:45:54PM +0530, Vasant Hegde wrote:
>>>  never
>>>  always
>>>  paging-only
>>>  secure-always
>>>  secure-paging-only
>>
>> Why not just expose supported modes (No ATS, ATS, Secure ATS) per group and
>> allow admin to select within supported modes?  We may have to add more logic in
>> sysfs store/show code path. But user will know what is supported and what they
>> can pick.
> 
> A sysfs type thing is what I'm thinking
> 
> Just trying to understand what options we should be providing to
> userspace..
> 
> I am sensitive that we'd like to disble ATS for identity modes in many
> common cases and we get that implicitly today.

In default boot, we can keep existing behavior right?

May be add more logic to sysfs show/store path? Meaning calculate per device
group supported options and expose only those. And in store path validate
against supported options?

> 
>> Also sysfs knob needs new domain ops to communicate changes to indivisual
>> driver. Like in store path
>>   - validate the input
>>   - make sure driver is unbond so that its safe to modify the
>>   - New ops to communicate to indivisual driver
>> 	 something like ops->set_ats_mode(dev, mode)
> 
> Yeah this needs to be considered.. I wonder if a flags input to attach
> is the right way to go.

You mean add `flag` to ops->attach_dev() ? That should work fine.

I said new ops because that would make updating existing domain/DTE becomes easy.

-Vasant

> 
> That would be convenient for how SMMUv3 is structued now as it can just
> switch modes hitlessly with its existing logic. I think all drivers
> should have a similar design.
> 
> Jason