"Yu, Fenghua" <fenghua.yu@xxxxxxxxx> writes: > Hi, Alistair, >> Alistair Popple <apopple@xxxxxxxxxx> writes: >> Lorenzo Stoakes <lstoakes@xxxxxxxxx> writes: >> > My concern is exposing something highly delicate _which accesses >> > remote mas a public API with implicit assumptions whose one and only >> > (core kernel) user treats with enormous caution. Even if this iommu >> > code were to use it correctly, we'd end up with an interface which could be >> subject to real risks which other drivers may misuse. >> >> Ok, although I think making this an iommu specific wrapper taking a PASID >> rather than mm_struct would make the API more specific and less likely to be >> misused as the mm_count/users lifetime issues could be dealt with inside the >> core IOMMU code. > > The iommu specific wrapper still needs to call access_remote_vm() which is > in generic mm. We cannot avoid to export access_remote_vm(), right? The wrapper still needs to call access_remote_vm(), but that doesn't imply access_remote_vm() needs to be exported. I think the logical place to put the wrapper would be in iommu-sva.c which isn't built as a module, so you would only have to EXPORT_SYMBOL_GPL the wrapper and not access_remote_vm(). > Are you saying the iommu specific wrapper doesn't need to the mm code? > > Thanks. > > -Fenghua
