Re: [PATCH 00/20] iommu: Refactoring domain allocation interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024/5/31 14:00, Baolu Lu wrote:
On 5/31/24 11:16 AM, Yi Liu wrote:
On 2024/5/29 20:02, Baolu Lu wrote:
On 2024/5/29 17:03, Yi Liu wrote:
On 2024/5/29 13:32, Lu Baolu wrote:
The IOMMU subsystem has undergone some changes, including the removal
of iommu_ops from the bus structure. Consequently, the existing domain
allocation interface, which relies on a bus type argument, is no longer
relevant:

     struct iommu_domain *iommu_domain_alloc(struct bus_type *bus)

This series is designed to refactor the use of this interface. It
proposes two new interfaces to replace iommu_domain_alloc():

- iommu_user_domain_alloc(): This interface is intended for allocating
   iommu domains managed by userspace for device passthrough scenarios,
   such as those used by iommufd, vfio, and vdpa. It clearly indicates
   that the domain is for user-managed device DMA.

user paging domain? It looks to me user domain includes the nested domains
as well.

Yes, nested domain is a user domain. The iommu driver should implement
iommu_ops->domain_alloc_user for nested domain allocation.

will it be more clear to name iommu_user_domain_alloc() be
iommu_user_paging_domain_alloc() as it is mainly for paging domain
allocation?

That might be better; let's wait and see if there's another option.



   If an IOMMU driver does not implement iommu_ops->domain_alloc_user,
   this interface will rollback to the generic paging domain allocation.

- iommu_paging_domain_alloc(): This interface is for allocating iommu
   domains managed by kernel drivers for kernel DMA purposes. It takes a
   device pointer as a parameter, which better reflects the current
   design of the IOMMU subsystem.

The majority of device drivers currently using iommu_domain_alloc() do
so to allocate a domain for a specific device and then attach that
domain to the device. These cases can be straightforwardly migrated to
the new interfaces.

However, there are some drivers with more complex use cases that do
not fit neatly into this new scheme. For example:

$ git grep "= iommu_domain_alloc"
arch/arm/mm/dma-mapping.c:      mapping->domain = iommu_domain_alloc(bus); drivers/gpu/drm/rockchip/rockchip_drm_drv.c:    private->domain = iommu_domain_alloc(private->iommu_dev->bus); drivers/gpu/drm/tegra/drm.c:            tegra->domain = iommu_domain_alloc(&platform_bus_type); drivers/infiniband/hw/usnic/usnic_uiom.c:       pd->domain = domain = iommu_domain_alloc(dev->bus);

This series leave those cases unchanged and keep iommu_domain_alloc()
for their usage. But new drivers should not use it anymore.

does it mean there is still domains allocated via iommu_domain_alloc()
on VT-d platform?

I think the drivers mentioned above do not run on x86 platforms, or do
they?

cool. BTW. I know out-of-tree drivers are not counted in upstream review.
Just out of curious, is there a formal way to let such drivers know it is
no longer allowed to use iommu_domain_alloc() on VT-d?

As Robin suggested, we should try to remove iommu_domain_alloc() from
the tree in this series.

If it's completely dropped, that's fine. OOT drivers should fail in the
time of compiling.

--
Regards,
Yi Liu



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux