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

[Jiri Pirko <jiri@resnulli.us>]

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.

[..]