linux-kernel - Re: [PATCH 1/2] PCI: endpoint: Introduce 'get

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: <Zp+4sDfopSiAdWt/@x1-carbon.lan>
Date: Tue, 23 Jul 2024 16:05:36 +0200
From: Niklas Cassel <cassel@...nel.org>
To: Rick Wertenbroek <rick.wertenbroek@...il.com>
Cc: Damien Le Moal <dlemoal@...nel.org>, rick.wertenbroek@...g-vd.ch,
	alberto.dassatti@...g-vd.ch,
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Krzysztof Wilczyński <kw@...ux.com>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>, Frank Li <Frank.Li@....com>,
	Lars-Peter Clausen <lars@...afoo.de>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] PCI: endpoint: Introduce 'get_bar' to map fixed
 address BARs in EPC

On Tue, Jul 23, 2024 at 09:41:14AM +0200, Rick Wertenbroek wrote:
> 
> Interesting. I like this approach, this would also make it possible to
> combine the current 'pci_epf_alloc_space' and 'pci_epc_set_bar' into a
> single function which would simplify the endpoint functions.
> 
> The reason why it is separate now is so that 'pci_epf_alloc_space' can
> be called before the endpoint function is bound to a controller, and
> therefore the BAR memory can be filled and prepared before bind() is
> called. Merging 'pci_epf_alloc_bar' with 'pci_epc_set_bar' into a
> 'pci_epc_alloc_bar' (epc because it is dependent on the endpoint
> controller and prior to be bound to a specific controller we don't
> know if we need to allocate locally or remap) would make it impossible
> to access the BAR prior to be bound to a controller (because the
> function 'pci_epc_alloc_bar' would fail without a specific
> controller). I don't think this is a problem as an unbound endpoint
> function is kind of useless on its own, but this means the BAR memory
> could only be allocated/remapped/accessed once the endpoint is bound
> to a controller.

Back when I was looking it to this, I came to the conclusion:
"The proper place is to allocate them when receiving PERST,
but not all drivers have a PERST handler."

However, since:
https://github.com/torvalds/linux/commit/a01e7214bef904723d26d293eb17586078610379

All EPF drivers should get a epc_init event, either directly when the EPC
driver is loaded, or when PERST# is asserted.

So I definitely agree that it makes sense for all EPF function drivers to do
both alloc_space() + set_bar() is a single call, now when that is possible.

This will simplify a lot of PCIe endpoint code considerably.


Kind regards,
Niklas