On Fri, Mar 03, 2023 at 10:24:42AM +0800, Baolu Lu wrote:
> > > > -int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t
> > > > max) +static int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t
> > > > min, ioasid_t max) {
> > > > - int ret = 0;
> > > > - ioasid_t pasid;
> > > > + int ret;
> > > > - if (min == INVALID_IOASID || max == INVALID_IOASID ||
> > > > + if (min == IOMMU_PASID_INVALID || max == IOMMU_PASID_INVALID ||
> > > > min == 0 || max < min)
> > >
> > > It's irrelevant to this patch. Just out of curiosity, why do we need to
> > > exclude PASID 0 here? I just had a quick look at PCI spec section 6.20.
> > > The spec does not state that PASID 0 is invalid.
> > >
> > my understanding is that ARM reserves PASID0, unlike VT-d where RID_PASID
> > is programmable.
It does, but that's specific to the IOMMU driver so we shouldn't check it
here.
> I suppose the common thing is reserving some kind of special PASIDs.
Are you planning to use RID_PASID != 0 in VT-d? Otherwise we could just
communicate min_pasid from the IOMMU driver the same way we do max_pasid.
Otherwise I guess re-introduce a lighter ioasid_alloc() that the IOMMU
driver calls to reserve PASID0/RID_PASID.
Thanks,
Jean
