Managing boot order dependencies with ResetNotification Protocol

["Ajay Iyengar (QUIC)" <quic_aiyengar@quicinc.com>]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

Hello,

This is a comment and query on the Reset Notification Protocol defined by the UEFI specification.

The specification requires clients to be notified for ResetSystem() without imposing any specific ordering on how these notifications are dispatched: https://uefi.org/specs/UEFI/2.10/39_Micellaneous_Protocols.html#reset-notification-protocol.
For example, this is used for gracefully shutting off NVMe and TPM through their respective spec defined power off notifications:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c#L950
https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c#L2597

If we assume a platform implementing fTPM using NVMe-RPMB,  the boot order would require NVMe as a dependency for TPM, but that might result in an issue with the reset notification path. The default EDK2 implementation dispatches these notifications in boot order: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c#L78.  Here NVMe would power off, before TPM commits to NVMe-RPMB within its reset notification callback. Reversing the order of dispatch (i.e. reverse-boot order) would help with this situation.

We have several similar situations on our platform -- drivers with a Depex ordering registering for ResetNotify which would benefit from being signaled in reverse-boot order. Are there any provisions that could be made with regards to ensuring the ordering requirement?  Could we mimic the behavior of the ExitBootServices event dispatch for ResetNotify:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Event/Event.c#L492 ?
[The proposal would be to use InsertHeadList() instead of InsertTailList() in RegisterResetNotify()]

Thanks,
Ajay

[-- Attachment #2: Type: text/html, Size: 7289 bytes --]