linux-kernel - Re: [PATCH v2] fpga: dfl: afu: support Rev 2 of DFL Port feature

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: <Zbnd8W1ciTKeoKc4@yilunxu-OptiPlex-7050>
Date: Wed, 31 Jan 2024 13:43:13 +0800
From: Xu Yilun <yilun.xu@...ux.intel.com>
To: matthew.gerlach@...ux.intel.com
Cc: hao.wu@...el.com, trix@...hat.com, mdf@...nel.org, yilun.xu@...el.com,
	linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] fpga: dfl: afu: support Rev 2 of DFL Port feature

On Tue, Jan 30, 2024 at 10:00:16AM -0800, matthew.gerlach@...ux.intel.com wrote:
> 
> 
> On Tue, 30 Jan 2024, Xu Yilun wrote:
> 
> > On Thu, Jan 25, 2024 at 03:37:15PM -0800, Matthew Gerlach wrote:
> > > Revision 2 of the Device Feature List (DFL) Port feature
> > > adds support for connecting the contents of the port to
> > > multiple PCIe Physical Functions (PF).
> > > 
> > > This new functionality requires changing the port reset
> > > behavior during FPGA and software initialization from
> > > revision 1 of the port feature. With revision 1, the initial
> > > state of the logic inside the port was not guaranteed to
> > > be valid until a port reset was performed by software during
> > > driver initialization. With revision 2, the initial state
> > > of the logic inside the port is guaranteed to be valid,
> > > and a port reset is not required during driver initialization.
> > > 
> > > This change in port reset behavior avoids a potential race
> > > condition during PCI enumeration when a port is connected to
> > > multiple PFs. Problems can occur if the driver attached to
> > > the PF managing the port asserts reset in its probe function
> > > when a driver attached to another PF accesses the port in its
> > > own probe function. The potential problems include failed or hung
> > 
> > Only racing during probe functions? I assume any time port_reset()
> > would fail TLPs for the other PF. And port_reset() could be triggered
> > at runtime by ioctl().
> 
> Yes, a port_reset() triggered by ioctl could result in failed TLP for the
> other PFs. The user space SW performing the ioctl needs to ensure all PFs
> involved are properly quiesced before the port_reset is performed.

How would user get an insight into other PF drivers to know everything
is quiesced?  I mean do we need driver level management for this?

Thanks,
Yilun

> 
> Do you want me to update the commit message with this information?
> 
> Thanks,
> Matthew