RE: [PATCH v4 00/12] Initial support for SMMUv3 nested translation

Tian, Kevin
2025-02-21T04:28:54Z

> From: Baolu Lu <baolu.lu@linux.intel.com>
> Sent: Thursday, February 20, 2025 7:49 PM
>
> On 2025/2/20 14:51, Tian, Kevin wrote:
> >> From: Baolu Lu<baolu.lu@linux.intel.com>
> >> Sent: Thursday, February 20, 2025 10:11 AM
> >>
> >> On 2/19/25 16:34, Tian, Kevin wrote:
> >>>> From: Baolu Lu<baolu.lu@linux.intel.com>
> >>>> Sent: Wednesday, February 19, 2025 10:10 AM
> >>>>
> >>>> On 2/18/25 21:03, Jason Gunthorpe wrote:
> >>>>> On Sat, Feb 15, 2025 at 05:53:13PM +0800, Baolu Lu wrote:
> >>>>>> On 2/14/25 20:41, Jason Gunthorpe wrote:
> >>>>>>> On Fri, Feb 14, 2025 at 01:39:52PM +0800, Baolu Lu wrote:
> >>>>>>>
> >>>>>>>> When the IOMMU is working in scalable mode, PASID and PRI are
> >>>> supported.
> >>>>>>>> ATS will always be enabled, even if the identity domain is attached
> to
> >>>>>>>> the device, because the PASID might use PRI, which depends on
> ATS
> >>>>>>>> functionality. This might not be the best choice, but it is the
> >>>>>>>> simplest and functional.
> >>>>>>> The arm driver keeps track of things and enables ATS when PASIDs
> are
> >>>>>>> present
> >>>>>> I am not aware of any VT-d hardware implementation that supports
> >>>>>> scalable mode but not PASID. If there were one, it would be
> worthwhile
> >>>>>> to add an optimization to avoid enabling ATS during probe if PASID is
> >>>>>> not supported.
> >>>>> I mean domains attached to PASIDs that need PRI/ATS/etc
> >>>> Yeah, that's a better solution. The PCI PRI/ATS features are only
> >>>> enabled when a domain that requires them is attached to it. I will
> >>>> consider it in the Intel driver later.
> >>>>
> >>> I didn't get the connection here. ATS can run w/o PASID per PCIe
> >>> spec. Why do we want to add a dependency on PASID here?
> >> It's due to PRI, which depends on ATS. The original topic is: when an
> >> identity domain is attached to the device and the device has no PASID
> >> support, then ATS might be disabled because ATS isn't supposed to
> >> provide much benefit in this case.
> > PRI depends on ATS but PASID is optional.
> >
> > ATS has no benefit (or even more cost) with identity domain but again
> > it has nothing to do with PASID.
> >
> >> Otherwise, ATS should be enabled because:
> >>
> >> - It benefits performance when the domain is a paging domain.
> >> - A domain attached to a PASID might use PRI, thus requiring ATS to be
> >> on.
> > Above talks about the domain type. Nothing specific to PASID.
> >
> >> The proposed solution is to use a reference count for ATS enablement,
> >> similar to how we handle iopf in another series. ATS is enabled as long
> >> as any domain requires it and disabled if no domain requires it.
> >>
> > I'm fine with using reference count for ATS enablement based on
> > the domain type, but just didn't get the role of PASID in this discussion.
>
> Sorry that I didn't make it clear. Let me try again.
>
> PASID is mentioned in this discussion because it makes things different.
>
> Without PASID support, only a single domain is attached to the device.
> ATS enablement can then be determined based on the domain type.
> Specifically:
>
> - For an identity domain, ATS could be disabled.
> - For other domains, ATS is enabled.
>
> With PASID support, multiple domains can be attached to the device, and
> each domain may have different ATS requirements. Therefore, we cannot
> simply determine the ATS status in the RID domain attach/detach paths. A
> better solution is to use the reference count, as mentioned above.
>

Okay, that helps connect the dots and makes sense to me. Thanks!