Re: [RFC PATCH v2 2/5] dma-mapping: Use the correct phys_to_dma() for DMA_RESTRICTED_POOL

[Mostafa Saleh <smostafa@google.com>]

On Thu, Apr 16, 2026 at 12:20:09PM +0530, Aneesh Kumar K.V wrote:
> Mostafa Saleh <smostafa@google.com> writes:
> 
> > On Mon, Apr 13, 2026 at 11:38:36AM +0530, Aneesh Kumar K.V wrote:
> >> Mostafa Saleh <smostafa@google.com> writes:
> >> 
> >> > As restricted dma pools are always decrypted, in swiotlb.c it uses
> >> > phys_to_dma_unencrypted() for address conversion.
> >> >
> >> > However, in DMA-direct, calls to phys_to_dma_direct() with
> >> > force_dma_unencrypted() returning false, will fallback to
> >> > phys_to_dma() which is inconsistent for memory allocated from
> >> > restricted dma pools.
> >> >
> >> > Fixes: f4111e39a52a ("swiotlb: Add restricted DMA alloc/free support")
> >> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> >> > ---
> >> >  kernel/dma/direct.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> >> > index 27d804f0473f..1a402bb956d9 100644
> >> > --- a/kernel/dma/direct.c
> >> > +++ b/kernel/dma/direct.c
> >> > @@ -26,7 +26,7 @@ u64 zone_dma_limit __ro_after_init = DMA_BIT_MASK(24);
> >> >  static inline dma_addr_t phys_to_dma_direct(struct device *dev,
> >> >  		phys_addr_t phys)
> >> >  {
> >> > -	if (force_dma_unencrypted(dev))
> >> > +	if (force_dma_unencrypted(dev) || is_swiotlb_for_alloc(dev))
> >> >  		return phys_to_dma_unencrypted(dev, phys);
> >> >
> >> 
> >> So what kind of device is this? Is it a trusted device that needs to use
> >> swiotlb in unencrypted form?(is that a valid use case?) Can we add additional comment
> >> explaining the type of device for which we are allocating the DMA
> >> buffer?
> >
> > That’s used for devices that use restricted-dma pools which are
> > currently always decrypted, typically virtio devices that are emulated
> > by the untrusted host.
> >
> 
> Why would those devices not force unencrypted DMA? Sorry, I may not be
> following all the details. The pool itself is decrypted by default, but
> the device does not force unencrypted DMA?”
> 

That’s the case at the moment for pKVM guests; that doesn’t use
force_dma_unencrypted(), and just rely on swiotlb.
When I was trying to enable that, I ended up with the double
encryption issue fixed in this series.
I believe that swiotlb and force_dma_unencrypted() are completely
independent and the code shouldn’t make any assumptions about those,
ideally force_dma_unencrypted() is a property of the device in a
protected guest and swiotlb is per pool.

Thanks,
Mostafa

> -aneesh