Re: [PATCH kernel 4/9] dma/swiotlb: Stop forcing SWIOTLB for TDISP devices

[<dan.j.williams@intel.com>]

Robin Murphy wrote:
> On 2026-02-25 4:30 pm, dan.j.williams@intel.com wrote:
> > Alexey Kardashevskiy wrote:
> >> SWIOTLB is enforced when encrypted guest memory is detected
> >> in pci_swiotlb_detect() which is required for legacy devices.
> >>
> >> Skip SWIOTLB for TDISP devices.
> >>
> >> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
> >> ---
> >>   include/linux/swiotlb.h | 9 +++++++++
> >>   1 file changed, 9 insertions(+)
> >>
> >> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> >> index 3dae0f592063..119c25d639a7 100644
> >> --- a/include/linux/swiotlb.h
> >> +++ b/include/linux/swiotlb.h
> >> @@ -173,6 +173,15 @@ static inline bool is_swiotlb_force_bounce(struct device *dev)
> >>   {
> >>   	struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> >>   
> >> +	/*
> >> +	 * CC_ATTR_GUEST_MEM_ENCRYPT enforces SWIOTLB_FORCE in
> >> +	 * swiotlb_init_remap() to allow legacy devices access arbitrary
> >> +	 * VM encrypted memory.
> >> +	 * Skip it for TDISP devices capable of DMA-ing the encrypted memory.
> >> +	 */
> >> +	if (device_cc_accepted(dev))
> >> +		return false;
> > 
> > I worry this further muddies the meaning of the swiotlb force option.
> > What if you want to force swiotlb operation on accepted devices?
> 
> For that we'd need a whole other private SWIOTLB plus the logic to 
> decide which one to use in the first place.

In this case I was still considering that swiotlb is still implicitly
only shared address bouncining. Indeed, a whole other "private_swiotlb"
mechanism would be needed for private bouncing. Not clear there is a
need for that at present.

Even for this swiotlb=force for "accepted" devices I only see a
potential kernel development use case, not a deployment use case.

> option to forcibly expose all DMA through shared memory regardless of 
> TDISP and friends, that would logically want to be a higher-level CoCo 
> option rather than belonging to SWIOTLB itself ;)

As I have it below, yes, CoCo opts into this bounce_unaccepted mechanism.

As to your other question:

> (since a device that's trusted to access private memory
> isn't necessarily prohibited from still also accessing shared memory as
> well), hmmm...

The specification allows it, but Linux DMA mapping core is not yet ready
for it. So the expectation to start is that the device loses access to
its original shared IOMMU mappings when converted to private operation.

So on ARM where shared addresses are high, it is future work to figure
out how an accepted device might also access shared mappings outside the
device's dma_mask.

> > For example:
> > 
> > @@ -173,7 +176,13 @@ static inline bool is_swiotlb_force_bounce(struct device *dev)
> >   {
> >          struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> >   
> > -       return mem && mem->force_bounce;
> > +       if (!mem)
> > +               return false;
> > +       if (mem->force_bounce)
> > +               return true;
> > +       if (mem->bounce_unaccepted && !device_cc_accepted(dev))
> > +               return true;
> > +       return false;
> >   }
> >   
> >   void swiotlb_init(bool addressing_limited, unsigned int flags);