Hi Jason, On Tue, 11 May 2021 13:35:21 -0300, Jason Gunthorpe <j...@nvidia.com> wrote:
> On Tue, May 11, 2021 at 09:14:52AM -0700, Jacob Pan wrote: > > > > Honestly, I'm not convinced we should have "kernel SVA" at all.. Why > > > does IDXD use normal DMA on the RID for kernel controlled accesses? > > > > Using SVA simplifies the work submission, there is no need to do > > map/unmap. Just bind PASID with init_mm, then submit work directly > > either with ENQCMDS (supervisor version of ENQCMD) to a shared > > workqueue or put the supervisor PASID in the descriptor for dedicated > > workqueue. > > That is not OK, protable drivers in Linux have to sue dma map/unmap > calls to manage cache coherence. PASID does not opt out of any of > that. > Let me try to break down your concerns: 1. portability - driver uses DMA APIs can function w/ and w/o IOMMU. is that your concern? But PASID is intrinsically tied with IOMMU and if the drivers are using a generic sva-lib API, why they are not portable? SVA by its definition is to avoid map/unmap every time. 2. cache coherence - as you suggested if we name the flag "direct_map", there is no mapping change, then there is no need for mmu_notifier like tlb flush calls, right? it is caller's responsibility to make sure vmalloc are not used. > I dislike this whole idea a lot. A single driver should not opt itself > out of IOMMU based security "just because" > Perhaps I missed your point here. This is NOT a single driver, privileged access is a PCIe spec defined feature. We are using IOMMU sva-lib APIs, not sure why it is by-passing. Perhaps we should add check for struct pci_dev->untrusted && rciep to address security? > Jason Thanks, Jacob _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
