Messages in this thread Patch in this message | | | Date | Wed, 1 Apr 2020 10:13:30 -0700 | From | Jacob Pan <> | Subject | Re: [PATCH V10 06/11] iommu/vt-d: Add bind guest PASID support |
| |
On Tue, 31 Mar 2020 03:43:39 +0000 "Tian, Kevin" <kevin.tian@intel.com> wrote:
> > > > struct intel_svm_dev { > > > > @@ -698,9 +700,13 @@ struct intel_svm_dev { > > > > struct intel_svm { > > > > struct mmu_notifier notifier; > > > > struct mm_struct *mm; > > > > + > > > > struct intel_iommu *iommu; > > > > int flags; > > > > int pasid; > > > > + int gpasid; /* Guest PASID in case of vSVA bind with > > > > non-identity host > > > > + * to guest PASID mapping. > > > > + */ > > > > > > we don't need to highlight identity or non-identity thing, since > > > either way shares the same infrastructure here and it is not the > > > knowledge that the kernel driver should assume > > > > > Sorry, I don't get your point. > > > > What I meant was that this field "gpasid" is only used for > > non-identity case. For identity case, we don't have > > SVM_FLAG_GUEST_PASID. > > what's the problem if a guest tries to set gpasid even in identity > case? do you want to add check to reject it? Also I remember we > discussed before that we want to provide a consistent interface > to other consumer e.g. KVM to setup VMCS PASID translation table. > In that case, regardless of identity or non-identity, we need provide > such mapping info. The solution is in flux a little. For KVM to set up VMCS, we are planning to use IOASID set private ID as guest PASID. So this part of the code will go away, i.e. G-H PASID mapping will no longer stored in IOMMU driver. Perhaps we can address this after the transition?
| |