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

[Jiri Pirko <jiri@resnulli.us>]

Wed, May 06, 2026 at 03:39:32PM +0200, jmoroni@google.com wrote:
>> transparent dmabuf-backed-VA pinning
>
>Thanks! I took a look at your WIP code. It seems like it would really simplify
>things for irdma. Looking forward to it.
>
>Is there a WIP you can share for any rdma-core changes? For example, I
>am wondering if there will be some generic allocation helper for drivers to
>allocate umems for internal use (for QP rings, etc.). This helper would
>detect if it's running in a CVM and use the cc_shared heap or something.
>
>I'm mainly just curious how you see it being used on the userspace side.

https://github.com/jpirko/rdma-core/commits/wip_umem_bufs/


>
>>>> 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?
>
>This would have been a driver hack and doesn't make sense compared to
>your current plan, but the idea would have been to use the DMA allocator in
>the kernel to allocate the QP rings. This would give us a public buffer, which
>could then be mapped into the process with dma_mmap_coherent which
>sets the pages to decrypted. I imagine this scheme would be needed for
>NICs that require physically contiguous ring buffers (if any exist, not sure).
>
>Thanks,
>Jake