linux-kernel - Re: [PATCH v4] PCI: hotplug: Add OCTEON PCI hotplug controller driver

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: <20241112160833.GA1845767@bhelgaas>
Date: Tue, 12 Nov 2024 10:08:33 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Shijith Thotton <sthotton@...vell.com>
Cc: "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>,
	"Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"rafael@...nel.org" <rafael@...nel.org>,
	"scott@...amperecomputing.com" <scott@...amperecomputing.com>,
	Jerin Jacob <jerinj@...vell.com>,
	Srujana Challa <schalla@...vell.com>,
	Vamsi Krishna Attunuru <vattunuru@...vell.com>
Subject: Re: [PATCH v4] PCI: hotplug: Add OCTEON PCI hotplug controller driver

On Tue, Nov 12, 2024 at 09:25:46AM +0000, Shijith Thotton wrote:
> >> This patch introduces a PCI hotplug controller driver for the OCTEON
> >> PCIe device. The OCTEON PCIe device is a multi-function device where the
> >> first function serves as the PCI hotplug controller.
> >>
> >>                +--------------------------------+
> >>                |           Root Port            |
> >>                +--------------------------------+
> >>                                |
> >>                               PCIe
> >>                                |
> >> +---------------------------------------------------------------+
> >> |              OCTEON PCIe Multifunction Device                 |
> >> +---------------------------------------------------------------+
> >>              |                    |              |            |
> >>              |                    |              |            |
> >> +---------------------+  +----------------+  +-----+  +----------------+
> >> |      Function 0     |  |   Function 1   |  | ... |  |   Function 7   |
> >> | (Hotplug controller)|  | (Hotplug slot) |  |     |  | (Hotplug slot) |
> >> +---------------------+  +----------------+  +-----+  +----------------+
> >>              |
> >>              |
> >> +-------------------------+
> >> |   Controller Firmware   |
> >> +-------------------------+
> >>
> >> The hotplug controller driver enables hotplugging of non-controller
> >> functions within the same device. During probing, the driver removes
> >> the non-controller functions and registers them as PCI hotplug slots.
> >> These slots are added back by the driver, only upon request from the
> >> device firmware.
> >>
> >> The controller uses MSI-X interrupts to notify the host of hotplug
> >> events initiated by the OCTEON firmware. Additionally, the driver
> >> allows users to enable or disable individual functions via sysfs slot
> >> entries, as provided by the PCI hotplug framework.
> >
> >Can we say something here about what the benefit of this driver is?
> >For example, does it save power?
> 
> The driver enables hotplugging of non-controller functions within the device
> without requiring a fully implemented switch, reducing both power consumption
> and product cost.

Reduced product cost is motivation for the hardware design, not for
this hotplug driver.

You didn't explicitly say that when function 0 hot-removes another
function, it reduces overall power consumption.  But I assume that's
the case?

> >What causes the function 0 firmware to request a hot-add or
> >hot-removal of another function?
> 
> The firmware will enable the required number of non-controller
> functions based on runtime demand, allowing control over these
> functions. For example, in a vDPA scenario, each function could act
> as a different type of device (such as net, crypto, or storage)
> depending on the firmware configuration.

What is the path for this runtime demand?  I assume function 0
provides some interface to request a specific kind of functionality
(net, crypo, storage, etc)?

I don't know anything about vDPA, so if that's important here, it
needs a little more context.

> Hot removal is useful in cases of live firmware updates.

So the idea is that function X is hot-removed, which forces the driver
to let go of it, the firmware is updated, and X is hot-added again,
and the driver binds to it again?

And somewhere in there is a reset of function X, and after the reset
X is running the new firmware?

Who/what initiates this whole path?  Some request to function 0,
saying "please remove function X"?

But I guess maybe it doesn't go through function 0, since octeon_hp
claims function 0, and it doesn't provide that functionality.  Maybe
the individual drivers for *other* functions know how to initiate
these things, and those functions internally communicate with function
0 to ask it to start a hot-remove/hot-add sequence?

That wouldn't explain the power reduction plan, though.  A driver for
function X could conceivably tell its device "I'm no longer needed"
and function X could tell function 0 to remove it.  That might enable
some power savings.  But that doesn't have a path to *re-enable*
function X, since function X has been removed and there's no driver to
ask for it to be hot-added again.

Maybe there's some out-of-band management path that can tell function
0 to do things, independent of PCIe?

So confused,
  Bjorn