Re: [PATCH rdma-next 2/2] RDMA/umem: block plain userspace memory registration under CoCo bounce

[Jiri Pirko <jiri@resnulli.us>]

Tue, May 05, 2026 at 06:02:50PM +0200, jgg@ziepe.ca wrote:
>On Tue, May 05, 2026 at 09:20:01AM -0400, Jacob Moroni wrote:
>> Hi,
>> 
>> Out of curiosity, it seems like we set DMA_ATTR_REQUIRE_COHERENT, so
>> would that have caused these registrations to fail anyway since it would
>> be trying to use swiotlb if running in a CVM?
>
>It is supposed to, at least that is the intention. I think that
>new attribute overtook Jiri's patch here?

Yeah, my patch seems to be redundant now.


>
>> I was hoping that the new cc_shared heap could be used without
>> modifying the kernel driver by replacing the normal allocations in the provider
>> with a dmabuf allocation+mmap and just passing the resulting pointer to reg_mr,
>> but that won't work because it's a PFN mapping.
>
>> The driver could be modified to accept the actual dmabuf instead for the QP/CQ
>> rings, but I just wanted to see if that matches your vision here or if
>> you had something
>> else in mind. 
>
>Jiri has been looking at both options, but kernel side irdma must be
>upgraded to accept a dmabuf for every kind of userspace memory.

Correct, the transparent dmabuf-backed-VA pinning is still in pipes, as
it is based on https://lore.kernel.org/all/20260504135731.2345383-1-jiri@resnulli.us/
Check it out in my working branch here:
https://github.com/jpirko/linux_mlxsw/commit/00c51b20a977bb63681d140d65d857f978b3b8a6


>
>This is why we have been trying to centralize more of the umem logic
>because every driver should be upgraded to accept dmabuf for
>everything...
>
>> Another idea was to just allocate them in the kernel using the DMA
>> allocator and map them into userspace but it would be a larger change.
>
>This isn't the pattern we are using in rdma..

Yeah, plus I'm missing the motivation, what that would help us to
achieve?