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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240904100507.u3speeqf5ncopjhc@joelS2.panther.com>
Date: Wed, 4 Sep 2024 12:05:07 +0200
From: Joel Granados <j.granados@...sung.com>
To: Baolu Lu <baolu.lu@...ux.intel.com>
CC: Jason Gunthorpe <jgg@...pe.ca>, Klaus Jensen <its@...elevant.dk>, "David
 Woodhouse" <dwmw2@...radead.org>, Joerg Roedel <joro@...tes.org>, Will
	Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>, Kevin Tian
	<kevin.tian@...el.com>, Minwoo Im <minwoo.im@...sung.com>,
	<linux-kernel@...r.kernel.org>, <iommu@...ts.linux.dev>, Klaus Jensen
	<k.jensen@...sung.com>
Subject: Re: [PATCH RFC PREVIEW 0/6] iommu: enable user space iopfs in
 non-nested and non-svm cases

On Wed, Sep 04, 2024 at 09:37:35AM +0800, Baolu Lu wrote:
> 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.

Thx for the clarification. I'll make sure to include them in my V1

Best

-- 

Joel Granados