On Tue, 31 Mar 2020 03:43:39 +0000 "Tian, Kevin" <kevin.t...@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? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu