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(). This looks better than exporting access_remote_vm(). I will remove this patch and write the IOMMU wrapper to call access_remote_vm() in v2. Thanks. -Fenghua
