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

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

On 2025/2/25 22:55, Jason Gunthorpe wrote:
> On Tue, Feb 25, 2025 at 01:18:43PM +0000, Robin Murphy wrote:
> 
>>> My thought is to add a flag in iommufd_hw_capabilities to report the
>>> capability, and add a flag in iommufd_hwpt_alloc_flags to let iommu driver
>>> know if HPT is needed when allocating S2 domain. Userspace attaches the
>>> un-trusted devices to the domains with HPT. While trusted devices can be
>>> attached to 'normal' S2 domains.  Will to send it out soon.:)
>>>
>>>> With Secure ATS, for ATS requests IOMMU return GPA to device instead
>>>> of SPA.
>>>
>>> I suppose AMD Secure ATS only works under nested translation configuration.
>>> is it? I guess admin may want some flexibility to opt-in it. :)
>>
>> Heh, and in SMMUv3 we have both options, with split-stage ATS for nested
>> translation, and our Device Permission Table for full ATS, so it seems like
>> there should be room for some kind of generalised capability.
> 
> Yes, lets not have another driver-only command line parameter but
> somthing global managed by the core code.
> 
> What are the options here?
>   1) Translated Address (TA) is a full physical address and IOMMU does
>      do anything (today)
> 
do you mean "do nothing"?

>   2) IOMMU converts a S1 IOVA into a TA as a S2 IOVA address and the
>      IOMMU runs it through the S2 to validate it. (ARM calls this
>      split-stage). Requires nesting
> 
>   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
> 
>   4) TA is an full physical address and the IOMMU validates the full
>      physical using some kind of permission structure (ARM calls this
>      Device Permission Table)
> 
> What are the three HWs doing?
> 
> I see #2 and #4 clearly in the SMM spec. Is #3 a special case of #2 (a
> STE with a S2 and S1DSS bypass)?
> 
> I think AMD is doing #3 from the docs.
> 
> What is Intel doing?

Intel does #4. It has a Host Permission Table which validates the
physical address.

4.2.4 Host Permission Table
The Host Permission Table (HPT) allows software to control access to the 
physical address space when
one or more devices uses translated requests. System software may create 
one or more domains
which permit memory accesses from only those ATS-devices that are accepted 
as part of the domain’s
Trusted Computing Base (TCB). HPT is only supported when operating in 
scalable mode. The HPT is a
4-level structure described in Table 11 and an example HPT Walk in Figure 
4-2. Each table entry
corresponding to a valid page size can reference one or more valid pages 
using the Page Permission
(PPi) fields as well as providing a pointer to the subsequent paging structure.

> A domain alloc flag to put the domain into #3 mode seems like a good
> start to me. The core code can decide to activate the flag for the
> default domain. Suggest starting from pci->untrusted.
> 
> Also, #3 requires PCI topology support, the ACS flags need to be set
> to route all TA's to the host. The core code should check and validate
> this before turning it on.

yes. I think both #2 and #3 need to enforce it. The TA device got is
not really a PA in the two modes.

> I think #2 can be requested through the vSTE on ARM?
> 
> Not sure how to setup #4? The core code also needs to detect coherent
> systems (ie CXL/etc) and refuse to do anything other than #1/#4..

The DPT and the HPT validates physical addresses. So such tables need to be
programmed when a physical address is mapped in I/O page table. So the
choice may be associating it with paging domain (e.g. the S2 domain that
converts GPA to PA). If so, a domain alloc flag is also a good start.

-- 
Regards,
Yi Liu