Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 11 May 2021 11:05:50 -0700 | From | Jacob Pan <> | Subject | Re: [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit flags |
| |
Hi Jason,
On Tue, 11 May 2021 13:35:21 -0300, Jason Gunthorpe <jgg@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
| ![\](/images/icornerr.gif) |