On Fri, Oct 15, 2021 at 01:29:16AM +0000, Tian, Kevin wrote: > Hi, Jason, > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Wednesday, September 29, 2021 8:59 PM > > > > On Wed, Sep 29, 2021 at 12:38:35AM +0000, Tian, Kevin wrote: > > > > > /* If set the driver must call iommu_XX as the first action in probe() or > > > * before it attempts to do DMA > > > */ > > > bool suppress_dma_owner:1; > > > > It is not "attempts to do DMA" but more "operates the physical device > > in any away" > > > > Not having ownership means another entity could be using user space > > DMA to manipulate the device state and attack the integrity of the > > kernel's programming of the device. > > > > Does suppress_kernel_dma sounds better than suppress_dma_owner? > We found the latter causing some confusion when doing internal > code review. Somehow this flag represents "don't claim the kernel dma > ownership during driver binding". suppress_dma_owner sounds the > entire ownership is disabled... If in doubt make it suppress_iommu_whatever_the_api_is_that_isn't_called > Another thing is about DMA_OWNER_SHARED, which is set to indicate > no dma at all. Thinking more we feel that this flag is meaningless. Its > sole purpose is to show compatibility to any USER/KERNEL ownership, > and essentially the same semantics as a device which is not bound to > any driver. So we plan to remove it then pci-stub just needs one line > change to set the suppress flag. But want to check with you first in case > any oversight. It sounds reasonable, but also makes it much harder to find the few places that have this special relationship - ie we can't grep for DMA_OWNER_SHARED anymore. Jason
