> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx> > Sent: Thursday, February 20, 2025 7:49 PM > > On 2025/2/20 14:51, Tian, Kevin wrote: > >> From: Baolu Lu<baolu.lu@xxxxxxxxxxxxxxx> > >> Sent: Thursday, February 20, 2025 10:11 AM > >> > >> On 2/19/25 16:34, Tian, Kevin wrote: > >>>> From: Baolu Lu<baolu.lu@xxxxxxxxxxxxxxx> > >>>> 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!
