Re: [PATCH v1 4/8] dma-mapping: Keep DMA memory private for capable devices

[Jason Gunthorpe]

On Wed, Oct 28, 2026 at 10:42:15AM +0000, Shameer Kolothum Thodi wrote:

> > @@ -1552,7 +1552,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device
> > *dev, phys_addr_t orig_addr,
> >  	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
> > 
> >  		/* swiotlb pool is incorrect for this device */
> > -		if (unlikely(mem->cc_shared !=
> > force_dma_unencrypted(dev)))
> > +		if (unlikely(mem->cc_shared != dma_require_decrypted(dev)))
> 
> Just wondering, what if a device with CC_PRIVATE set has addressing
> limitations and needs a private bounce buffer?  Or is that not a use case
> at all? 

Then it will correctly fail here because it is not implemented. This
protects accidently copying what should have been private data into
shared memory.

If someone ever needs this they will have to implement a swiotlb pool
for private memory along side the shared pool.

But a device that can't reach all of private wont' be able to reach
shared either, so it is basically fully broken, don't do that. The VMM
Should be setting the address layout of the VM so that the devices it
installs 'fit' within their addressing constraints. ie do not create a
VM with a 52 bit address space when your device only supports 48.

Jason