Re: [PATCH RFC PREVIEW 0/6] iommu: enable user space iopfs in non-nested and non-svm cases

[Baolu Lu]

On 9/3/24 9:20 PM, Joel Granados wrote:
> On Mon, Sep 02, 2024 at 08:47:21PM +0800, Baolu Lu wrote:
> > On 2024/9/2 18:48, Joel Granados wrote:
> > > > I definitely expect PRI to work outside PASID and SVA cases, so this
> > > > is going in a good direction
> > > This touches on a detail (at least in Intel's vtd-io spec) that is not
> > > 100% clear to me. Second paragraph of section "3.4.3 Scalable Mode
> > > Address Translation" reads:
> > > "
> > >     ... Scalable-mode context-entries support both requests-without-PASID
> > >     and requests-with-PASID. However unlike legacy mode, in scalable-mode,
> > >     requests-without-PASID obtain a PASID value from the RID_PASID field of
> > >     the scalable-mode context- entry and are processed similarly to
> > >     requests-with-PASID.Implementations not supporting RID_PASID capability
> > >     (ECAP_REG.RPS is 0b), use a PASID value of 0 to perform address
> > >     translation for requests without PASID.
> > > "
> > > This basically means that a default PASID is used even though the
> > > request is without PASID. Right? Therefore "outside PASID" means with
> > > the default PASID (at least in Intels case). Right?
> > Kind of yes.
> >
> > The PCI specification defines the concept of PASID and its role in
> > transaction routing. We refer to PCI transactions with a PASID prefix as
> > "request-with-PASID" and those without a PASID prefix as "request-
> > without-PASID." Consequently, I understand 'outside PASID' to mean
> > transactions that do not have a PASID prefix.
> >
> > The VT-d specification describes how the IOMMU hardware handles request-
> > without-PASID. It uses a reserved PASID for its internal routing and
> > handling purposes. If RID_PASID is supported (ECAP_REG.RPS=1), software
> > can select its own reserved PASID. Otherwise, the IOMMU hardware will
> > use a default value of 0.
> Thx for getting back to me. This generates another doubt in my head
> regarding the published capabilities from the intel IOMMU Hardware:
>
> So ecap_pasid [1] does not have to be set in scalable-mode. Right? This
> allows hardware supporting scalable-mode to reject transactions with
> PASID whenever ecap_pasid is*NOT*  set; even though internally things
> are handled with a PASID. This question is directly related to the two
> last patches in the set.5/6 and 6/6.

Yes. And 5/6, 6/6 make sense to me. We should remove the PASID
restriction from the code once PRI is split from SVA.

Thanks,
baolu