Re: [PATCH RFC 21/26] dma-buf: Add the Physical Address List DMA mapping type

["Christian König" <christian.koenig@amd.com>]

On 4/13/26 14:16, Jason Gunthorpe wrote:
> On Mon, Apr 13, 2026 at 10:58:20AM +0200, Christian König wrote:
>> On 2/18/26 01:11, Jason Gunthorpe wrote:
>>> This type is required by iommufd and kvm as dmabuf importers.
>>>
>>> Due to sensitivity about abusing physical addresses, restrict importers by
>>> using EXPORT_SYMBOL_FOR_MODULES(). Only iommufd can implement an importer,
>>> the kernel module loader will enforce this.
>>>
>>> Allow anything to implement an exporter as there are use cases in
>>> DPDK/SPDK to connect GPU memory into VFIO/iommufd and it is hard to abuse
>>> the API as an exporter.
>>>
>>> The physical address list exporter returns a physical address list in a
>>> simple kvalloc'd array of struct phys_vec.
>>
>> As far as I can see that is still a pretty big NO-GO.
>>
>> We have seen so many problems with direct physical address access by
>> the importer that I clear don't want to repeat that performance.
> 
> You've said, this is why I used the EXPORT_SYMBOL_FOR_MODULES() -
> iommufd does not have any problems to use this correctly.
> 
> Why is that not good enough? As I understand it your objection isn't
> that there is a technical issue with iommufd's implementation it is
> that some other driver could import phys, do it wrong and make a
> mess. I think EXPORT_SYMBOL_FOR_MODULES() fully addresses this, no?

No, not even remotely. I clearly don't want such an interface in DMA-buf at all.

You can do that as private iommufd interface, e.g. where iommufd offers the functionality to say give me PFNs if you want that.

But when there is a DMA-buf interface even if it is limited to iommufd then others will want that as well and that is not something we should do again.

Even for iommufd I think we don't need that. What iommufd does is basically manipulating a specific IOMMU address space. So the interface should be to give that address space to DMA-buf and say hey please map you backing store at this address into this address space.

Regards,
Christian.

> The only past problems you've raised were related to improperly using
> VMAs, that isn't happening here.
> 
>> My main question is why does IOMMUFD need the physical address in
>> the first place?
> 
> CPU iommu hw only works in physical address.
> 
>> If that is really strictly necessary then I strongly suggest to not
>> touch drivers/dma-buf in any way, but only do this is private
>> interface between iommufd and KVM.
> 
> This isn't between iommufd and kvm. If it was just that we'd probably
> be able to keep going with the private path like VFIO/iommufd already
> has.
> 
> The two paths we are interested in:
> 
> 1) VFIO to KVM
>    Allow KVM to import a FD instead of using a VMA like iommufd now can.
> 2) GPU and RDMA drivers to IOMMUFD
>    Support SPDK and DPDK type userspace drivers to work with GPU memory
>    This is becoming a popular topic
> 
> Jason