[PATCH rdma-next v2 0/2] RDMA: detect and handle CoCo DMA bounce buffering

[PATCH rdma-next v2 0/2] RDMA: detect and handle CoCo DMA bounce buffering

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

In Confidential Computing (CoCo) guests, the DMA mapping layer
redirects all device DMA through swiotlb bounce buffers to keep guest
memory encrypted. This is transparent for regular devices because the
CPU copies data between the bounce buffer and the real buffer on every
DMA map/unmap cycle.

RDMA breaks this model. Once a memory region is registered, the device
accesses the underlying pages directly for an extended period without
CPU involvement. The swiotlb layer never gets a chance to synchronize,
so the device operates on bounce buffer memory while the application
works with its own pages - the two never see each other's updates.

This series adds detection and handling of this condition. A new
IB_UVERBS_DEVICE_CC_DMA_BOUNCE flag is exposed in device_cap_flags_ex
so userspace libraries can detect the situation and switch to
dmabuf-based memory registration using "system_cc_shared" heap
where available. Plain __ib_umem_get_va() is made to fail early with
-EOPNOTSUPP to have more specific error code instead of existing -EIO
caused by DMA_ATTR_REQUIRE_COHERENT.

---
See individual patches for changelog.

v1: https://lore.kernel.org/all/20260505061149.2361536-1-jiri@resnulli.us/

based on top of:
https://lore.kernel.org/all/20260504135731.2345383-1-jiri@resnulli.us/

Jiri Pirko (2):
  RDMA/uverbs: expose CoCo DMA bounce requirement to userspace
  RDMA/umem: block plain userspace memory registration under CoCo bounce

 drivers/infiniband/core/device.c     | 6 ++++++
 drivers/infiniband/core/umem.c       | 3 +++
 drivers/infiniband/core/uverbs_cmd.c | 2 ++
 include/rdma/ib_verbs.h              | 3 +++
 include/uapi/rdma/ib_user_verbs.h    | 2 ++
 5 files changed, 16 insertions(+)

-- 
2.53.0

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

[Jiri Pirko]

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))
+		device->cc_dma_bounce = 1;
 
 	ret = setup_device(device);
 	if (ret)
diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c
index 240f8a0cfd86..2a70774c639a 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -3655,6 +3655,8 @@ static int ib_uverbs_ex_query_device(struct uverbs_attr_bundle *attrs)
 	resp.timestamp_mask = attr.timestamp_mask;
 	resp.hca_core_clock = attr.hca_core_clock;
 	resp.device_cap_flags_ex = attr.device_cap_flags;
+	if (ib_dev->cc_dma_bounce)
+		resp.device_cap_flags_ex |= IB_UVERBS_DEVICE_CC_DMA_BOUNCE;
 	resp.rss_caps.supported_qpts = attr.rss_caps.supported_qpts;
 	resp.rss_caps.max_rwq_indirection_tables =
 		attr.rss_caps.max_rwq_indirection_tables;
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 167fb924f0cf..d06071b87d96 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -275,6 +275,7 @@ enum ib_device_cap_flags {
 	IB_DEVICE_FLUSH_GLOBAL = IB_UVERBS_DEVICE_FLUSH_GLOBAL,
 	IB_DEVICE_FLUSH_PERSISTENT = IB_UVERBS_DEVICE_FLUSH_PERSISTENT,
 	IB_DEVICE_ATOMIC_WRITE = IB_UVERBS_DEVICE_ATOMIC_WRITE,
+	IB_DEVICE_CC_DMA_BOUNCE = IB_UVERBS_DEVICE_CC_DMA_BOUNCE,
 };
 
 enum ib_kernel_cap_flags {
@@ -2950,6 +2951,8 @@ struct ib_device {
 	u16                          kverbs_provider:1;
 	/* CQ adaptive moderation (RDMA DIM) */
 	u16                          use_cq_dim:1;
+	/* CoCo guest with DMA bounce buffering required */
+	u16                          cc_dma_bounce:1;
 	u8                           node_type;
 	u32			     phys_port_cnt;
 	struct ib_device_attr        attrs;
diff --git a/include/uapi/rdma/ib_user_verbs.h b/include/uapi/rdma/ib_user_verbs.h
index 3b7bd99813e9..d2aeadb6d2f9 100644
--- a/include/uapi/rdma/ib_user_verbs.h
+++ b/include/uapi/rdma/ib_user_verbs.h
@@ -1368,6 +1368,8 @@ enum ib_uverbs_device_cap_flags {
 	IB_UVERBS_DEVICE_FLUSH_PERSISTENT = 1ULL << 39,
 	/* Atomic write attributes */
 	IB_UVERBS_DEVICE_ATOMIC_WRITE = 1ULL << 40,
+	/* CoCo guest with DMA bounce buffering required */
+	IB_UVERBS_DEVICE_CC_DMA_BOUNCE = 1ULL << 41,
 };
 
 enum ib_uverbs_raw_packet_caps {
-- 
2.53.0

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

[Leon Romanovsky]

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.

Thanks

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

[Jiri Pirko]

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

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

[Jason Gunthorpe]

On Tue, May 12, 2026 at 04:03:07PM +0200, Jiri Pirko wrote:
> >> @@ -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.

For now CC_ATTR_GUEST_MEM_ENCRYPT is likely sufficient.

Later we should be able to detect if the device is in T=1 mode
directly.

Jason

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

[Jiri Pirko]

Tue, May 12, 2026 at 04:05:10PM CEST, jgg@ziepe.ca wrote:
>On Tue, May 12, 2026 at 04:03:07PM +0200, Jiri Pirko wrote:
>> >> @@ -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.
>
>For now CC_ATTR_GUEST_MEM_ENCRYPT is likely sufficient.
>
>Later we should be able to detect if the device is in T=1 mode
>directly.

Okay, so we assume for now that every device is T=0 (which I believe is
the reality). Once T=1 device appears, it changes this "if statement".
Do I understand that correctly?

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

[Jason Gunthorpe]

On Tue, May 12, 2026 at 04:08:44PM +0200, Jiri Pirko wrote:
> Tue, May 12, 2026 at 04:05:10PM CEST, jgg@ziepe.ca wrote:
> >On Tue, May 12, 2026 at 04:03:07PM +0200, Jiri Pirko wrote:
> >> >> @@ -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.
> >
> >For now CC_ATTR_GUEST_MEM_ENCRYPT is likely sufficient.
> >
> >Later we should be able to detect if the device is in T=1 mode
> >directly.
> 
> Okay, so we assume for now that every device is T=0 (which I believe is
> the reality). Once T=1 device appears, it changes this "if statement".
> Do I understand that correctly?

Yes, that is what I was thinking

Jason

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

[Jiri Pirko]

Tue, May 12, 2026 at 04:34:02PM CEST, jgg@ziepe.ca wrote:
>On Tue, May 12, 2026 at 04:08:44PM +0200, Jiri Pirko wrote:
>> Tue, May 12, 2026 at 04:05:10PM CEST, jgg@ziepe.ca wrote:
>> >On Tue, May 12, 2026 at 04:03:07PM +0200, Jiri Pirko wrote:
>> >> >> @@ -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.
>> >
>> >For now CC_ATTR_GUEST_MEM_ENCRYPT is likely sufficient.
>> >
>> >Later we should be able to detect if the device is in T=1 mode
>> >directly.
>> 
>> Okay, so we assume for now that every device is T=0 (which I believe is
>> the reality). Once T=1 device appears, it changes this "if statement".
>> Do I understand that correctly?
>
>Yes, that is what I was thinking

Okay, I'll leave some comment for future generations. Thanks!

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

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

When a device requires DMA bounce buffering inside a Confidential
Computing guest, __ib_umem_get_va() cannot work. The DMA mapping layer
redirects all mappings through swiotlb bounce buffers, so the device
receives DMA addresses pointing to bounce buffer memory rather than
the user's pages. 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.

The registration would already fail later on, since the umem mapping
is requested with DMA_ATTR_REQUIRE_COHERENT and gets rejected under
is_swiotlb_force_bounce() with -EIO. Fail early with -EOPNOTSUPP
instead, so the user gets a specific error code to react to.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
---
v1->v2:
- updated patch description with mention of DMA_ATTR_REQUIRE_COHERENT
---
 drivers/infiniband/core/umem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 611d693eb9a2..b1877b83b021 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -167,6 +167,9 @@ static struct ib_umem *__ib_umem_get_va(struct ib_device *device,
 	int pinned, ret;
 	unsigned int gup_flags = FOLL_LONGTERM;
 
+	if (device->cc_dma_bounce)
+		return ERR_PTR(-EOPNOTSUPP);
+
 	/*
 	 * If the combination of the addr and size requested for this memory
 	 * region causes an integer overflow, return error.
-- 
2.53.0

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

[Leon Romanovsky]

On Wed, May 06, 2026 at 01:14:47PM +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@nvidia.com>
> 
> When a device requires DMA bounce buffering inside a Confidential
> Computing guest, __ib_umem_get_va() cannot work. The DMA mapping layer
> redirects all mappings through swiotlb bounce buffers, so the device
> receives DMA addresses pointing to bounce buffer memory rather than
> the user's pages. 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.
> 
> The registration would already fail later on, since the umem mapping
> is requested with DMA_ATTR_REQUIRE_COHERENT and gets rejected under
> is_swiotlb_force_bounce() with -EIO. Fail early with -EOPNOTSUPP
> instead, so the user gets a specific error code to react to.

DMA_ATTR_REQUIRE_COHERENT was our answer to "layering violation claim".

Thanks

> 
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
> v1->v2:
> - updated patch description with mention of DMA_ATTR_REQUIRE_COHERENT
> ---
>  drivers/infiniband/core/umem.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index 611d693eb9a2..b1877b83b021 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -167,6 +167,9 @@ static struct ib_umem *__ib_umem_get_va(struct ib_device *device,
>  	int pinned, ret;
>  	unsigned int gup_flags = FOLL_LONGTERM;
>  
> +	if (device->cc_dma_bounce)
> +		return ERR_PTR(-EOPNOTSUPP);
> +
>  	/*
>  	 * If the combination of the addr and size requested for this memory
>  	 * region causes an integer overflow, return error.
> -- 
> 2.53.0
> 

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

[Jiri Pirko]

Tue, May 12, 2026 at 03:05:15PM CEST, leon@kernel.org wrote:
>On Wed, May 06, 2026 at 01:14:47PM +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@nvidia.com>
>> 
>> When a device requires DMA bounce buffering inside a Confidential
>> Computing guest, __ib_umem_get_va() cannot work. The DMA mapping layer
>> redirects all mappings through swiotlb bounce buffers, so the device
>> receives DMA addresses pointing to bounce buffer memory rather than
>> the user's pages. 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.
>> 
>> The registration would already fail later on, since the umem mapping
>> is requested with DMA_ATTR_REQUIRE_COHERENT and gets rejected under
>> is_swiotlb_force_bounce() with -EIO. Fail early with -EOPNOTSUPP
>> instead, so the user gets a specific error code to react to.
>
>DMA_ATTR_REQUIRE_COHERENT was our answer to "layering violation claim".

I'm not sure I follow. What's the issue you see?




>
>Thanks
>
>> 
>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> ---
>> v1->v2:
>> - updated patch description with mention of DMA_ATTR_REQUIRE_COHERENT
>> ---
>>  drivers/infiniband/core/umem.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
>> index 611d693eb9a2..b1877b83b021 100644
>> --- a/drivers/infiniband/core/umem.c
>> +++ b/drivers/infiniband/core/umem.c
>> @@ -167,6 +167,9 @@ static struct ib_umem *__ib_umem_get_va(struct ib_device *device,
>>  	int pinned, ret;
>>  	unsigned int gup_flags = FOLL_LONGTERM;
>>  
>> +	if (device->cc_dma_bounce)
>> +		return ERR_PTR(-EOPNOTSUPP);
>> +
>>  	/*
>>  	 * If the combination of the addr and size requested for this memory
>>  	 * region causes an integer overflow, return error.
>> -- 
>> 2.53.0
>> 

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

[Leon Romanovsky]

On Tue, May 12, 2026 at 04:04:13PM +0200, Jiri Pirko wrote:
> Tue, May 12, 2026 at 03:05:15PM CEST, leon@kernel.org wrote:
> >On Wed, May 06, 2026 at 01:14:47PM +0200, Jiri Pirko wrote:
> >> From: Jiri Pirko <jiri@nvidia.com>
> >> 
> >> When a device requires DMA bounce buffering inside a Confidential
> >> Computing guest, __ib_umem_get_va() cannot work. The DMA mapping layer
> >> redirects all mappings through swiotlb bounce buffers, so the device
> >> receives DMA addresses pointing to bounce buffer memory rather than
> >> the user's pages. 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.
> >> 
> >> The registration would already fail later on, since the umem mapping
> >> is requested with DMA_ATTR_REQUIRE_COHERENT and gets rejected under
> >> is_swiotlb_force_bounce() with -EIO. Fail early with -EOPNOTSUPP
> >> instead, so the user gets a specific error code to react to.
> >
> >DMA_ATTR_REQUIRE_COHERENT was our answer to "layering violation claim".
> 
> I'm not sure I follow. What's the issue you see?

SWIOTLB is the layer below DMA API, RDMA is the layer above DMA API.
You shouldn't call to SWIOTLB functions in RDMA code.

Thanks

> 
> 
> 
> 
> >
> >Thanks
> >
> >> 
> >> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> >> ---
> >> v1->v2:
> >> - updated patch description with mention of DMA_ATTR_REQUIRE_COHERENT
> >> ---
> >>  drivers/infiniband/core/umem.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >> 
> >> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> >> index 611d693eb9a2..b1877b83b021 100644
> >> --- a/drivers/infiniband/core/umem.c
> >> +++ b/drivers/infiniband/core/umem.c
> >> @@ -167,6 +167,9 @@ static struct ib_umem *__ib_umem_get_va(struct ib_device *device,
> >>  	int pinned, ret;
> >>  	unsigned int gup_flags = FOLL_LONGTERM;
> >>  
> >> +	if (device->cc_dma_bounce)
> >> +		return ERR_PTR(-EOPNOTSUPP);
> >> +
> >>  	/*
> >>  	 * If the combination of the addr and size requested for this memory
> >>  	 * region causes an integer overflow, return error.
> >> -- 
> >> 2.53.0
> >> 

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

[Jiri Pirko]

Thu, May 14, 2026 at 06:25:06PM +0200, leon@kernel.org wrote:
>On Tue, May 12, 2026 at 04:04:13PM +0200, Jiri Pirko wrote:
>> Tue, May 12, 2026 at 03:05:15PM CEST, leon@kernel.org wrote:
>> >On Wed, May 06, 2026 at 01:14:47PM +0200, Jiri Pirko wrote:
>> >> From: Jiri Pirko <jiri@nvidia.com>
>> >> 
>> >> When a device requires DMA bounce buffering inside a Confidential
>> >> Computing guest, __ib_umem_get_va() cannot work. The DMA mapping layer
>> >> redirects all mappings through swiotlb bounce buffers, so the device
>> >> receives DMA addresses pointing to bounce buffer memory rather than
>> >> the user's pages. 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.
>> >> 
>> >> The registration would already fail later on, since the umem mapping
>> >> is requested with DMA_ATTR_REQUIRE_COHERENT and gets rejected under
>> >> is_swiotlb_force_bounce() with -EIO. Fail early with -EOPNOTSUPP
>> >> instead, so the user gets a specific error code to react to.
>> >
>> >DMA_ATTR_REQUIRE_COHERENT was our answer to "layering violation claim".
>> 
>> I'm not sure I follow. What's the issue you see?
>
>SWIOTLB is the layer below DMA API, RDMA is the layer above DMA API.
>You shouldn't call to SWIOTLB functions in RDMA code.

This patch doesn't do that. The patch description only describes the
current situation and how the patch changes the behaviour.

[..]

Re: [PATCH rdma-next v2 0/2] RDMA: detect and handle CoCo DMA bounce buffering

[Jacob Moroni]

Reviewed-by: Jacob Moroni <jmoroni@google.com>