Yi,
On 8/16/2024 5:22 PM, Yi Liu wrote:
> On 2024/8/16 16:29, Vasant Hegde wrote:
>> Yi,
>>
>>
>> On 8/15/2024 7:42 AM, Yi Liu wrote:
>>> On 2024/8/14 22:40, Jason Gunthorpe wrote:
>>>> On Wed, Aug 14, 2024 at 04:19:13PM +0800, Yi Liu wrote:
>>>>
>>>>> /**
>>>>> * enum iommufd_hw_capabilities
>>>>> * @IOMMU_HW_CAP_DIRTY_TRACKING: IOMMU hardware support for dirty tracking
>>>>> * If available, it means the following APIs
>>>>> * are supported:
>>>>> *
>>>>> * IOMMU_HWPT_GET_DIRTY_BITMAP
>>>>> * IOMMU_HWPT_SET_DIRTY_TRACKING
>>>>> *
>>>>> */
>>>>> enum iommufd_hw_capabilities {
>>>>> IOMMU_HW_CAP_DIRTY_TRACKING = 1 << 0,
>>>>> };
>>>>
>>>> I think it would be appropriate to add the flag here
>>>
>>> ok.
>>>
>>>> Is it OK to rely on the PCI config space PASID enable? I see all the
>>>> drivers right now are turning on PASID support during probe if the
>>>> iommu supports it.
>>>
>>> Intel side is not ready yet as it enables pasid when the device is attached
>>> to a non-blocking domain. I've chatted with Baolu, and he will kindly to
>>> enable the pasid cap in the probe_device() op if both iommu and device has
>>> this cap. After that, Intel side should be fine to rely on the PASID enable
>>> bit in the PCI config space.
>>>
>>> How about SMMU and AMD iommu side? @Jason, @Suravee, @Vasant?
>>
>> AMD driver currently discovers capability in probe_device() and enabled it in
>> attach_dev() path.
>
> I see. So AMD side also has a gap. Is it easy to make it suit Jason's
> suggestion in the above?
We can do that. We can enable ATS, PRI and PASID capability during probe time
and keep it enabled always.
-Vasant
