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

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

Kevin,


On 2/28/2025 11:45 AM, Tian, Kevin wrote:
>> From: Baolu Lu <baolu.lu@linux.intel.com>
>> Sent: Friday, February 28, 2025 9:48 AM
>>
>> On 2/28/25 00:04, Vasant Hegde wrote:
>>> On 2/26/2025 12:40 PM, Tian, Kevin wrote:
>>>>> From: Vasant Hegde<vasant.hegde@amd.com>
>>>>> Sent: Wednesday, February 26, 2025 12:47 PM
>>>>>
>>>>>>   3) TA is an IOVA and the IOMMU runs it through the full translation
>>>>>>      to validate it. ATS is just used to signal non-present
>>>>> Yes. AMD does this when Host page table is configured.
>>>> Here 'signal non-present' implies to support PRI.
>>>>
>>>> But...
>>>>
>>>>> We need to consider various scenarios. For AMD:
>>>>>    - Currently on baremetal, we cannot enable SVA and Secure ATS
>>>> ... here it says SVA/SATS are incompatible. Any more background?
>>> Sorry. I should have explained it better.
>>>
>>> To support SVA (PASID/PRI), we have to configure domain with AMD Guest
>> (v2) Page
>>> table and host page table will not be set (DTE[Mode]=0).
>>>
>>>    GVA -> GPA contains translation and GPA = SPA.
>>>
>>> On ATS request it will send GPA back to device (which is actually a SPA). We
>> can
>>> support secure ATS, but ATS response will contain the SPA.
>>
>> So, the hardware is configured to work in secure ATS mode, but the ATS
>> is not actually secure here, right? AMD's secure ATS relies on checking
>> GPA to SPA translation; however, GPA is always equal to SPA in the SVA
>> case.
>>
>> Am I understanding this correctly?
>>
> 
> Looks so.
> 
> To support secure ATS, the IOMMU needs a structure to manage the
> permission per the translated address (TA).
> 
> For #2 it reuses the S2 page table for permission track hence requires
> nesting and TA = S2 IOVA. It cannot support bare metal SVA given
> S2 is absent.
> 
> AMD is clearly this flavor. also supported by ARM.
> 
> For #3 it reuses the full translation (s1, s2, or nested) with TA =
> untranslated IOVA. This supposes to work with all existing ATS
> scenarios. Probably good for prototype development but no
> real value given it loses all perf benefit from ATS or even worse
> perf compared to no ats due to double walking.
> 
> Both #2/#3 have PCI topology restrictions e.g. CXL.
> 
> ARM probably supports #3 as a special case of #2.
> 
> For #4, it introduces a separate permission structure per real
> physical address, hence TA = physical address. It's supposed
> to work for all ATS scenarios and CXL, with some burden e.g.
> sync with IO page table plus more invalidations, etc.

Nice Summary. #2 / #4 is practically useful scenario's.

-Vasant