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

[Leon Romanovsky <leon@kernel.org>]

On Fri, May 15, 2026 at 08:13:17AM +0200, Jiri Pirko wrote:
> 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.

From previous patch:
+       if (dma_device &&
+           cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+           is_swiotlb_force_bounce(dma_device))
+               device->cc_dma_bounce = 1;

And this patch reads cc_dma_bounce.

Thanks


> 
> [..]