Re: [RFC PATCH 0/1] DOE usage with pcie/portdrv

[Lukas Wunner <lukas@wunner.de>]

On Mon, May 09, 2022 at 10:48:06AM +0100, Jonathan Cameron wrote:
> On Sat, 7 May 2022 12:18:48 +0200 Lukas Wunner <lukas@wunner.de> wrote:
> > I'm still somewhat undecided on the kernel vs. user space question.
> 
> Likewise.  I feel a few more prototypes are needed to come to clear
> conclusion.

Gavin Hindman (+cc) raised an important point off-list:

When an IDE-capable device is runtime suspended to D3hot and later
runtime resumed to D0, it may not preserve its internal state.
(The No_Soft_Reset bit in the Power Management Control/Status Register
tells us whether the device is capable of preserving internal state
over a transition to D3hot, see PCIe r6.0, sec. 7.5.2.2.)

Likewise, when an IDE-capable device is reset (e.g. due to Downstream
Port Containment, AER or a bus reset initiated by user space),
internal state is lost and must be reconstructed by pci_restore_state().
That state includes the SPDM session or IDE encryption.

If setting up an SPDM session is dependent on user space, the kernel
would have to leave a device in an inoperable state after runtime resume
or reset, until user space gets around to initiate SPDM.

I think that would be a terrible user experience.  We've gone to great
lengths to make reset recovery as seamless and quick as possible.
(E.g. hot-plugged NVMe drives survive a reset without the driver being
unbound, those would be prime candidates for IDE encryption.)
It won't help the acceptance of IDE if it breaks that seamlessness.

So that's a strong argument for an in-kernel SPDM implementation.

Thanks,

Lukas