On Tue, 28 Feb 2023 18:24:41 +1100 Alexey Kardashevskiy <aik@xxxxxxx> wrote: > On 28/2/23 16:43, Lukas Wunner wrote: > > On Tue, Feb 28, 2023 at 12:18:07PM +1100, Alexey Kardashevskiy wrote: > >> On 11/2/23 07:25, Lukas Wunner wrote: > >>> For the same reason a DOE instance cannot be shared between the PCI core > >>> and a driver. > >> > >> And we want this sharing why? Any example will do. Thanks, > > > > The PCI core is going to perform CMA/SPDM authentication when a device > > gets enumerated (PCIe r6.0 sec 6.31). That's the main motivation > > to lift DOE mailbox creation into the PCI core. It's not mentioned > > here explicitly because I want the patch to stand on its own. > > CMA/SPDM support will be submitted separately. > > I was going the opposite direction with avoiding adding this into the > PCI core as 1) the pci_dev struct is already 2K and 2) it is a niche > feature and 3) I wanted this CMA/SPDM session setup to be platform > specific as on our platform the SPDM support requires some devices to be > probed before we can any SPDM. Is that happening over a DOE mailbox, or a different transport? If it's a different transport then that should be fine, though we'll need to have a slightly different security model and any part of early driver load will need to be carefully hardened against a "malicious" device if it is doing anything non trivial. If it's just "turning on the lights" then shouldn't be a problem. Will be interesting to see how niche DOE ends up. My guess it it's worth a struct xarray, but we could take it out of line if that saves enough to bother. > > > > A driver that later on gets bound to the device should be allowed > > to talk to it via DOE as well, possibly even sharing the same DOE > > mailboxes used by the PCI core. > > > > Patches for CMA/SPDM are under development on this branch: > > > > https://github.com/l1k/linux/commits/doe > > yes, thanks! Lots of reading :) > > > >>> Currently a DOE instance cannot be shared by multiple drivers because > >>> each driver creates its own pci_doe_mb struct for a given DOE instance. > >> > >> Sorry for my ignorance but why/how/when would a device have multiple drivers > >> bound? Or it only one driver at the time but we also want DOE MBs to survive > >> switching to another (different or newer) driver? > > > > Conceivably, a driver may have the need to talk to multiple devices > > via DOE, even ones it's not bound to. (E.g. devices in its ancestry > > or children.) > > Ah ok. Well, a parent device could look for the DOE MB in a child using > devres_find(), this requirement alone does not require moving things to > the PCI core and potentially allows it to be a module which could be a > better way as distros could have it always enabled but it would not > waste any memory on my laptop when not loaded. Thanks, The DOE mailboxes have an "exciting" level of flexibility and discovering supported protocols requires use of the DOE itself. So we need a single entity to take control over concurrent access to each DOE instance. Given the mix of protocols, I'd expect some of them to be potentially accessed by a parent, and others to be accessed by driver attached to the child. Whether it needs to chat to it's parent isn't totally clear to me yet, as depends a bit on what entities end up getting created for management of encryption etc + what other usecases we see in medium term. Jonathan
