From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma-mailsvcp-mx-lapp02.apple.com (ma-mailsvcp-mx-lapp02.apple.com [17.32.222.23]) by mx.groups.io with SMTP id smtpd.web10.1555.1689118688996660006 for ; Tue, 11 Jul 2023 16:38:09 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=VMz55tQC; spf=pass (domain: apple.com, ip: 17.32.222.23, mailfrom: afish@apple.com) Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma-mailsvcp-mx-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0RXN002NPOB5JP40@ma-mailsvcp-mx-lapp02.apple.com> for devel@edk2.groups.io; Tue, 11 Jul 2023 16:38:08 -0700 (PDT) X-Proofpoint-GUID: lQFVX6KBDIAAuabgWQfGLVlKfpJhUAWq X-Proofpoint-ORIG-GUID: lQFVX6KBDIAAuabgWQfGLVlKfpJhUAWq X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.591,18.0.957 definitions=2023-07-11_09:2023-07-11,2023-07-11 signatures=0 X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 adultscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307110153 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=/XaIYk3TCprJ01Y68f8/JiQ6JNsiHYqb+rJ3VBgoA3w=; b=VMz55tQCs6Rb6qyHRZKDzpRMS4tk4h04qIvm5VlVYoaBzXAZvyRnxT+CeTrU1FhM/Jm4 tMNjXaN32wnlOqXA4nQxjQ9B/16O+iG3yji+fKaOKFyAN2uU2tRDGJoBDddRXcossO1g 7mxTO/FanclOxM1r7HUTrFV+MQZia3Yj4NTXCEcHtYEh/VdL45W/45qeAhvdnVTZbf3+ +Ee0RqknPQk5k4GFy9yTtDSEyjRfdbC7EZUcWDGK8xOcZ4mEP3YsXCldEfibcvSXMzba XInE5voKWqcBlsPDK4r+IaK6lbbYi98+1cjdntTTbCwGF703VmUX5xmy9uOm1N3ND04O 2w== Received: from rn-mailsvcp-policy-lapp01.rno.apple.com (rn-mailsvcp-policy-lapp01.rno.apple.com [17.179.253.18]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0RXN00LZIOBAL050@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 11 Jul 2023 16:37:58 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-policy-lapp01.rno.apple.com by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) id <0RXN00400OA00R00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Tue, 11 Jul 2023 16:37:58 -0700 (PDT) X-Va-A: X-Va-T-CD: c3c2070957a3a1681b9c5cf0b23d5f24 X-Va-E-CD: e2bb78e3149ed2b6d12b168999089408 X-Va-R-CD: e40288c9c3a11f5799fd2003aff67346 X-Va-ID: 74df203a-c404-4653-9ef4-38446c433765 X-Va-CD: 0 X-V-A: X-V-T-CD: c3c2070957a3a1681b9c5cf0b23d5f24 X-V-E-CD: e2bb78e3149ed2b6d12b168999089408 X-V-R-CD: e40288c9c3a11f5799fd2003aff67346 X-V-ID: 51a9ef1b-303e-4edf-aab3-43b688f12d2e X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.591,18.0.957 definitions=2023-07-11_12:2023-07-11,2023-07-11 signatures=0 Received: from smtpclient.apple (unknown [17.11.208.168]) by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPSA id <0RXN00W5OOB9SZ00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Tue, 11 Jul 2023 16:37:58 -0700 (PDT) From: "Andrew Fish" Message-id: <6722125E-303D-497D-8AA3-A290590A893D@apple.com> MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Managing boot order dependencies with ResetNotification Protocol Date: Tue, 11 Jul 2023 16:37:47 -0700 In-reply-to: <7795152053a34b42ac9ffa2327eed287@quicinc.com> Cc: "devel@edk2.groups.io" , "Leif Lindholm (QUIC)" , Mike Kinney , Ruiyu Ni , Star Zeng , Michael Rothmam , Felix Poludov To: "Ajay Iyengar (QUIC)" References: <7795152053a34b42ac9ffa2327eed287@quicinc.com> X-Mailer: Apple Mail (2.3731.700.6) Content-type: multipart/alternative; boundary="Apple-Mail=_C40C7A12-AF91-42C1-89FA-681535977F0A" --Apple-Mail=_C40C7A12-AF91-42C1-89FA-681535977F0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ajay, In general the order of dispatch when all the DEPEX evaluate to TRUE and = the oder of events are not defined by the specification.=20 I think you are trying to say stuff that dispatches later is higher up = the stack and it would make more sense to send the rest to things higher = up the stack?=20 I=E2=80=99m not sure how this would work in your example as the Tcg2Dxe = driver has a Depex of gEfiVariableArchProtocolGuid and the NVMe driver = is a UEFI_DRIVER so it has an implied Depex [1] that is more complex? To really fix we would probably need to add some kind of new protocol = tot he NVMe driver that lets drivers request the reset get delayed. It = would have a register, unregister, I=E2=80=99m Done. =20 The NVMe driver would do something like: 1) Register for the reset notification 2) Publish the new protocol 3) When the 1st driver registers the NVMe driver unregisters the reset = notification, or I guess it could just ignore it.=20 When the shutdown happens and the last registered driver calls back in = to say I=E2=80=99m Done then the NVMe driver can shutdown.=20 The other drivers will need to RegisterProtocolNotify so there is not = dispatch sequence dependency. I=E2=80=99m not sure that is the best solution, that is just the best I = have right now. [1] UEFI_DRIVER depends on all the protocols required to impelemnt all = the UEFI Boot and Runtime Services. = https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMai= n/DxeProtocolNotify.c#L21 = https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMai= n/DxeProtocolNotify.c#L80 Thanks, Andrew FIsh > On Jun 28, 2023, at 5:23 PM, Ajay Iyengar (QUIC) = wrote: >=20 > Hello, > =20 > This is a comment and query on the Reset Notification Protocol defined = by the UEFI specification. > =20 > 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-noti= fication-protocol.=20 > For example, this is used for gracefully shutting off NVMe and TPM = through their respective spec defined power off notifications:=20 > = https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Pci/NvmExpr= essDxe/NvmExpressHci.c#L950 > = https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Dxe/Tcg2= Dxe.c#L2597 > =20 > 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/Reset= SystemRuntimeDxe/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. > =20 > 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()] > =20 > Thanks, > Ajay --Apple-Mail=_C40C7A12-AF91-42C1-89FA-681535977F0A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ajay,

In general the order of = dispatch when all the DEPEX evaluate to TRUE and the oder of events are = not defined by the specification. 

I think = you are trying to say stuff that dispatches later is higher up the stack = and it would make more sense to send the rest to things higher up the = stack? 

I=E2=80=99m not sure how this = would work in your example as the Tcg2Dxe driver has a Depex of = gEfiVariableArchProtocolGuid and the NVMe driver is a UEFI_DRIVER so it = has an implied Depex [1] that is more = complex?

To really fix we would probably need = to add some kind of new protocol tot he NVMe driver that lets drivers = request the reset get delayed. It would have a register, unregister, = I=E2=80=99m Done.  
The NVMe driver would do something = like:
1) Register for the  reset = notification
2) Publish the new protocol
3) When the = 1st driver registers the NVMe driver unregisters the reset notification, = or I guess it could just ignore it. 

When = the shutdown happens and the last registered driver calls back in to say = I=E2=80=99m Done then the NVMe driver can shutdown. 
The = other drivers will need to RegisterProtocolNotify so there is not = dispatch sequence dependency.

I=E2=80=99m not = sure that is the best solution, that is just the best I have right = now.

[1] UEFI_DRIVER depends on all the = protocols required to impelemnt all the UEFI Boot and Runtime = Services.
https://github.com/tianocore/edk2/blob/= master/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c#L80
Thanks,

Andrew = FIsh

On Jun 28, 2023, at 5:23 = PM, Ajay Iyengar (QUIC) <quic_aiyengar@quicinc.com> = wrote:

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#res= et-notification-protocol. 
For example, this is used for = gracefully shutting off NVMe and TPM through their respective spec = defined power off notifications: 
 
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/Universa= l/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:
[The proposal would be = to use InsertHeadList() instead of = InsertTailList() in RegisterResetNotify()]
 
Thanks,
Ajay

= --Apple-Mail=_C40C7A12-AF91-42C1-89FA-681535977F0A--