Michael Kelley wrote: > From: Dan Williams <dan.j.willi...@intel.com> Sent: Wednesday, April 9, 2025 > 4:30 PM [..] > > Like PCIe TDISP the capability of this device to access private memory > > is a property of the bus and the iommu. However, acceptance of the > > device into private operation is a willful policy action. It needs to > > validate not only the device provenance and state, but also the Linux > > DMA layer requirements of not holding shared or swiotlb mappings over > > the "entry into private mode operation" event. > > To flesh this out the swiotlb aspect a bit, once a TDISP device has > gone private, how does it prevent the DMA layer from ever doing > bounce buffering through the swiotlb? My understanding is that > the DMA layer doesn't make any promises to not do bounce buffering. > Given the vagaries of memory alignment, perhaps add in a virtual > IOMMU, etc., it seems like a device driver can't necessarily predict > what DMA operations might result in bounce buffering. Does TDISP > anticipate needing a formal way to tell the DMA layer "don't bounce > buffer"? (and return an error instead?) Or would there be a separate > swiotlb memory pool that is private memory so that bounce buffer > could be done when necessary and still maintain confidentiality?
I expect step 1 is just add some rude errors / safety for attempting to convert the mode of a device while it has any DMA mappings established, and explicit failures for attempts to fallback to swiotlb for 'private_accepted' devices. The easiest way to enforce that a device does not cross the shared/private boundary while DMA mappings are live is to simply not allow that transition while a driver is bound (i.e. "dev->driver" is non-NULL).
