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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250711065156.0d51199e@kernel.org>
Date: Fri, 11 Jul 2025 06:51:56 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Parav Pandit <parav@...dia.com>
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

On Fri, 11 Jul 2025 02:52:23 +0000 Parav Pandit wrote:
> > 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.

I see, that explains it. Thanks Parav!