Re: [PATCH rdma-next v2 1/2] RDMA/uverbs: expose CoCo DMA bounce requirement to userspace

[Jiri Pirko <jiri@resnulli.us>]

Tue, May 12, 2026 at 03:03:29PM CEST, leon@kernel.org wrote:
>On Wed, May 06, 2026 at 01:14:46PM +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@nvidia.com>
>> 
>> In CoCo guests, device DMA to regular userspace memory does not work
>> because the DMA mapping layer redirects all mappings through swiotlb
>> bounce buffers. Since RDMA devices access registered memory directly
>> without CPU involvement, there is no opportunity for swiotlb to
>> synchronize between the bounce buffer and the original pages.
>> 
>> Expose this condition to userspace as IB_UVERBS_DEVICE_CC_DMA_BOUNCE
>> in device_cap_flags_exi.
>> 
>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> ---
>>  drivers/infiniband/core/device.c     | 6 ++++++
>>  drivers/infiniband/core/uverbs_cmd.c | 2 ++
>>  include/rdma/ib_verbs.h              | 3 +++
>>  include/uapi/rdma/ib_user_verbs.h    | 2 ++
>>  4 files changed, 13 insertions(+)
>> 
>> diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
>> index b89efaaa81ec..ad3da92c9318 100644
>> --- a/drivers/infiniband/core/device.c
>> +++ b/drivers/infiniband/core/device.c
>> @@ -42,6 +42,8 @@
>>  #include <linux/security.h>
>>  #include <linux/notifier.h>
>>  #include <linux/hashtable.h>
>> +#include <linux/cc_platform.h>
>> +#include <linux/swiotlb.h>
>>  #include <rdma/rdma_netlink.h>
>>  #include <rdma/ib_addr.h>
>>  #include <rdma/ib_cache.h>
>> @@ -1419,6 +1421,10 @@ int ib_register_device(struct ib_device *device, const char *name,
>>  	 */
>>  	WARN_ON(dma_device && !dma_device->dma_parms);
>>  	device->dma_device = dma_device;
>> +	if (dma_device &&
>> +	    cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
>> +	    is_swiotlb_force_bounce(dma_device))
>
>It is the wrong place. When I worked on my DMA series, I tried something
>similar (a call into SWIOTLB) to notify users that RDMA would not work.
>
>The general feedback was that this is a layering violation, and that any
>knowledge of SWIOTLB (and its API) should not leak out of the DMA API.
>
>You shouldn't call to is_swiotlb_force_bounce() here.

What do you suggest as alternative? We need to somehow tell the user
what is the situation.


>
>Thanks