Re: [PATCH v6 2/6] iommufd: Add IOMMU_HWPT_INVALIDATE

Yi Liu
2023-11-28T05:52:22Z

On 2023/11/21 13:19, Nicolin Chen wrote:
> On Tue, Nov 21, 2023 at 01:02:49PM +0800, Baolu Lu wrote:
>> On 11/17/23 9:07 PM, Yi Liu wrote:
>>> In nested translation, the stage-1 page table is user-managed but cached
>>> by the IOMMU hardware, so an update on present page table entries in the
>>> stage-1 page table should be followed with a cache invalidation.
>>>
>>> Add an IOMMU_HWPT_INVALIDATE ioctl to support such a cache invalidation.
>>> It takes hwpt_id to specify the iommu_domain, and a multi-entry array to
>>> support multiple invalidation requests in one ioctl.
>>>
>>> Check cache_invalidate_user op in the iommufd_hw_pagetable_alloc_nested,
>>> since all nested domains need that.
>>>
>>> Co-developed-by: Nicolin Chen<nicolinc@nvidia.com>
>>> Signed-off-by: Nicolin Chen<nicolinc@nvidia.com>
>>> Signed-off-by: Yi Liu<yi.l.liu@intel.com>
>>> ---
>>> drivers/iommu/iommufd/hw_pagetable.c | 35 +++++++++++++++++++++++++
>>> drivers/iommu/iommufd/iommufd_private.h | 9 +++++++
>>> drivers/iommu/iommufd/main.c | 3 +++
>>> include/uapi/linux/iommufd.h | 35 +++++++++++++++++++++++++
>>> 4 files changed, 82 insertions(+)
>>>
>>> diff --git a/drivers/iommu/iommufd/hw_pagetable.c b/drivers/iommu/iommufd/hw_pagetable.c
>>> index 2abbeafdbd22..367459d92f69 100644
>>> --- a/drivers/iommu/iommufd/hw_pagetable.c
>>> +++ b/drivers/iommu/iommufd/hw_pagetable.c
>>> @@ -238,6 +238,11 @@ iommufd_hwpt_nested_alloc(struct iommufd_ctx *ictx,
>>> rc = -EINVAL;
>>> goto out_abort;
>>> }
>>> + /* Driver is buggy by missing cache_invalidate_user in domain_ops */
>>> + if (WARN_ON_ONCE(!hwpt->domain->ops->cache_invalidate_user)) {
>>> + rc = -EINVAL;
>>> + goto out_abort;
>>> + }
>>> return hwpt_nested;
>>
>> The WARN message here may cause kernel regression when users bisect
>> issues. Till this patch, there are no drivers support the
>> cache_invalidation_user callback yet.
>
> Ah, this is an unintended consequence from our uAPI bisect to
> merge the nesting alloc first...
>
> Would removing the WARN_ON_ONCE be okay? Although having this
> WARN is actually the point here...

seems like we may need to remove it. how about your opinion, @Jason?

> Thanks
> Nic

--
Regards,
Yi Liu