On Tue, Oct 17, 2023 at 12:50:11PM -0300, Jason Gunthorpe wrote:
On Tue, Oct 17, 2023 at 04:55:12PM +0800, Yi Liu wrote:
On 2023/10/17 02:44, Nicolin Chen wrote:
On Mon, Oct 16, 2023 at 08:59:07AM -0300, Jason Gunthorpe wrote:
On Mon, Oct 16, 2023 at 03:03:04PM +0800, Yi Liu wrote:
Current nesting series actually extends HWPT_ALLOC ioctl to accept user data for allocating domain with vendor specific data. Nested translation happens to be the usage of it. But nesting requires invalidation. If we want to do further split, then this new series would be just "extending HWPT_ALLOC to accept vendor specific data from userspace". But it will lack of a user if nesting is separated. Is this acceptable? @Jason
I'd still like to include the nesting allocation and attach parts though, even if they are not usable without invalidation ..
This is the latest series that I reworked (in bottom-up order): iommu: Add a pair of helper to copy struct iommu_user_data{_array} iommufd: Add IOMMU_HWPT_INVALIDATE iommufd: Add a nested HW pagetable object iommufd: Share iommufd_hwpt_alloc with IOMMUFD_OBJ_HWPT_NESTED iommufd: Derive iommufd_hwpt_paging from iommufd_hw_pagetable iommufd: Rename IOMMUFD_OBJ_HW_PAGETABLE to IOMMUFD_OBJ_HWPT_PAGING iommufd/device: Add helpers to enforce/remove device reserved regions iommu: Add IOMMU_DOMAIN_NESTED and cache_invalidate_user op iommu: Pass in parent domain with user_data to domain_alloc_user op
following Jason's comment, it looks like we can just split the cache invalidation path out. Then the above looks good after removing "iommufd: Add IOMMU_HWPT_INVALIDATE" and also the cache_invalidate_user callback in "iommu: Add IOMMU_DOMAIN_NESTED and cache_invalidate_user op". Is it? @Jason
If it can make sense, sure. It would be nice to be finished with the alloc path
I can do the split today. Shall we have a domain_alloc_user op in VT-d driver? Can we accept a core series only? I understood it's better to have though...
Only this v4 has the latest array-based invalidation design. And it should be straightforward for drivers to define entry/request structures. It might be a bit rush to review/finalize it at the stage of rc6 though.
yes, before v4, the cache invalidation path is simple and vendor drivers have their own handling.
Have driver implementations of v4 been done to look at?
I think so: https://lore.kernel.org/linux-iommu/20230921075431.125239-10-yi.l.liu@intel....
Thanks Nicolin