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. 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.
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.
Hope it explains.
Thanks,
baolu
