linux-kernel - RE: [RFC net-next 1/4] net: Allow non parent devices to be used for ZC DMA

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:
 <CY8PR12MB71956FF1D74C1EAE3401891CDC4BA@CY8PR12MB7195.namprd12.prod.outlook.com>
Date: Fri, 11 Jul 2025 02:52:23 +0000
From: Parav Pandit <parav@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Dragos Tatulea <dtatulea@...dia.com>, "almasrymina@...gle.com"
	<almasrymina@...gle.com>, "asml.silence@...il.com" <asml.silence@...il.com>,
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon
 Horman <horms@...nel.org>, Saeed Mahameed <saeedm@...dia.com>, Tariq Toukan
	<tariqt@...dia.com>, Cosmin Ratiu <cratiu@...dia.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC net-next 1/4] net: Allow non parent devices to be used for
 ZC DMA



> From: Jakub Kicinski <kuba@...nel.org>
> Sent: 11 July 2025 05:29 AM
> Subject: Re: [RFC net-next 1/4] net: Allow non parent devices to be used for ZC
> DMA
> 
> On Thu, 3 Jul 2025 11:58:50 +0000 Parav Pandit wrote:
> > > In my head subfunctions are a way of configuring a PCIe PASID ergo
> > > they _only_ make sense in context of DMA.
> > SF DMA is on the parent PCI device.
> >
> > SIOV_R2 will have its own PCI RID which is ratified or getting ratified.
> > When its done, SF (as SIOV_R2 device) instantiation can be extended
> > with its own PCI RID. At that point they can be mapped to a VM.
> 
> AFAIU every PCIe transaction for a queue with a PASID assigned should have a
> PASID prefix. Why is a different RID necessary?
> CPUs can't select IOMMU context based on RID+PASID?
It can, however,
PASID is meant to be used for process isolation and not expected to be abused for identify the device.
Doing so, would also prohibits using PASID inside the VM. It requires another complex vPASID to pPASID translation.

Tagging MSI-X interrupts with PASID is another challenge.
For CC defining isolation boundary with RID+PASID was yet another hack.

There were other issues in splitting PASID for device scaling vs process scaling for dual use.

So it was concluded to opt to avoid that abuse and use the standard RID construct for device identification.