Messages in this thread | | | Date | Thu, 23 Sep 2021 09:40:50 -0700 | From | "Luck, Tony" <> | Subject | Re: [PATCH 5/8] x86/mmu: Add mm-based PASID refcounting |
| |
On Thu, Sep 23, 2021 at 04:36:50PM +0200, Thomas Gleixner wrote: > On Mon, Sep 20 2021 at 19:23, Fenghua Yu wrote: > > > > +#ifdef CONFIG_INTEL_IOMMU_SVM > > +void pasid_put(struct task_struct *tsk, struct mm_struct *mm); > > +#else > > +static inline void pasid_put(struct task_struct *tsk, struct mm_struct *mm) { } > > +#endif > > This code is again defining that PASID is entirely restricted to > INTEL. It's true, that no other vendor supports this, but PASID is > a non-vendor specific concept. > > Sticking this into INTEL code means that any other PASID implementation > has to rip it out again from INTEL code and make it a run time property. > > The refcounting issue should be the same for all PASID mechanisms which > attach PASID to a mm. What's INTEL specific about that? > > So can we pretty please do that correct right away?
It's a bit messy (surprise).
There are two reasons to hold a refcount on a PASID
1) The process has done a bind on a device that uses PASIDs
This one isn't dependent on Intel.
2) A task within a process is using ENQCMD (and thus holds a reference on the PASID because IA32_PASID MSR for this task has the PASID value loaded with the enable bit set).
This is (currently) Intel specific (until others implement an ENQCMD-like feature to allow apps to access PASID enabled devices without going through the OS).
Perhaps some better function naming might help? E.g. have a task_pasid_put() function that handles the process exit case separatley from the device unbind case.
void task_pasid_put(void) { if (!cpu_feature_enabled(X86_FEATURE_ENQCMD)) return;
if (current->has_valid_pasid) { mutex_lock(&pasid_mutex); iommu_sva_free_pasid(mm); mutex_unlock(&pasid_mutex); } }
-Tony
| |