public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, kuqin12@gmail.com
Cc: Michael D Kinney <michael.d.kinney@intel.com>,
	Liming Gao <gaoliming@byosoft.com.cn>,
	Zhiguang Liu <zhiguang.liu@intel.com>,
	Mike Turner <mikeyt@pobox.com>
Subject: Re: [edk2-devel] [PATCH v2 2/4] MdePkg: DelayedDispatch: Added WaitOnEvent interface
Date: Tue, 10 Oct 2023 10:46:12 +0200	[thread overview]
Message-ID: <1f7f2772-2cd4-ffa4-2ffa-628fe18f15c7@redhat.com> (raw)
In-Reply-To: <20231010001856.1567-3-kuqin12@gmail.com>

On 10/10/23 02:18, Kun Qin wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4496
> 
> This change adds a new interface for the delayed dispatch PPI. This
> new addition allows functional components relying on delayed dispatch
> callbacks to be managed/dispatched with definitive order.
> 
> The full defintion has been added into PI spec.
> 
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> Cc: Liming Gao <gaoliming@byosoft.com.cn>
> Cc: Zhiguang Liu <zhiguang.liu@intel.com>
> 
> Co-authored-by: Mike Turner <mikeyt@pobox.com>
> Signed-off-by: Kun Qin <kuqin12@gmail.com>
> ---
> 
> Notes:
>     v2:
>     - Fixed PI spec version number to v1.8 [Liming]
> 
>  MdePkg/Include/Ppi/DelayedDispatch.h | 26 ++++++++++++++++++--
>  1 file changed, 24 insertions(+), 2 deletions(-)

I have a question that admittedly targets the spec more than it targets
the implementation.

What is the envisaged programming model / use case for WaitOnEvent? How
are multiple PEIMs to interoperate via the UniqueId GUIDs? Some concrete
use case would be good to know.

Second: the WaitOnEvent function can wait for completion in one of two ways:

(a) by calling back into the PEI dispatcher,

(b) by longjumping to the PEI dispatcher, and then the PEI dispatcher
longjumping back to WaitOnEvent.

Option (b) seems complicated (although not unseen in edk2; we frequently
use StackSwitch for various purposes, and see for example the Exit()
boot service -- that can *only* work with longjump).

Option (a) seems problematic, because if multiple PEIMs use ("nest")
WaitOnEvent, then we get repeated stack frames that all stand for the
PEI dispatcher. Stack space is considered "premium" during PEI; because
-- for example -- otherwise we wouldn't have
EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH, opposing
EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK.

Thanks,
Laszlo

> 
> diff --git a/MdePkg/Include/Ppi/DelayedDispatch.h b/MdePkg/Include/Ppi/DelayedDispatch.h
> index 098d57758551..0efcfdbfced6 100644
> --- a/MdePkg/Include/Ppi/DelayedDispatch.h
> +++ b/MdePkg/Include/Ppi/DelayedDispatch.h
> @@ -1,5 +1,5 @@
>  /** @file
> -    EFI Delayed Dispatch PPI as defined in the PI 1.7 Specification
> +    EFI Delayed Dispatch PPI as defined in the PI 1.8 Specification
>  
>      Provide timed event service in PEI
>  
> @@ -50,6 +50,7 @@ This service is the single member function of the EFI_DELAYED_DISPATCH_PPI
>    @param[in] This           Pointer to the EFI_DELAYED_DISPATCH_PPI instance
>    @param[in] Function       Function to call back
>    @param[in] Context        Context data
> +  @param[in] UniqueId       GUID for this Delayed Dispatch request.
>    @param[in] Delay          Delay interval
>  
>    @retval EFI_SUCCESS               Function successfully loaded
> @@ -63,9 +64,29 @@ EFI_STATUS
>    IN  EFI_DELAYED_DISPATCH_PPI      *This,
>    IN  EFI_DELAYED_DISPATCH_FUNCTION  Function,
>    IN  UINT64                         Context,
> +  IN  EFI_GUID                      *UniqueId   OPTIONAL,
>    IN  UINT32                         Delay
>    );
>  
> +/**
> +  Wait on a registered Delayed Dispatch unit that has a UniqueId.  Continue
> +  to dispatch all registered delayed dispatch entries until *ALL* entries with
> +  UniqueId have completed.
> +
> +  @param[in]     This            The Delayed Dispatch PPI pointer.
> +  @param[in]     UniqueId        UniqueId of delayed dispatch entry.
> +
> +  @retval EFI_SUCCESS            The operation succeeds.
> +  @retval EFI_INVALID_PARAMETER  The parameters are invalid.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EFI_DELAYED_DISPATCH_WAIT_ON_EVENT)(
> +  IN  EFI_DELAYED_DISPATCH_PPI      *This,
> +  IN  EFI_GUID                      *UniqueId
> +  );
> +
>  ///
>  /// This PPI is a pointer to the Delayed Dispatch Service.
>  /// This service will be published by the Pei Foundation. The PEI Foundation
> @@ -73,7 +94,8 @@ EFI_STATUS
>  /// execution.
>  ///
>  struct _EFI_DELAYED_DISPATCH_PPI {
> -  EFI_DELAYED_DISPATCH_REGISTER    Register;
> +  EFI_DELAYED_DISPATCH_REGISTER         Register;
> +  EFI_DELAYED_DISPATCH_WAIT_ON_EVENT    WaitOnEvent;
>  };
>  
>  extern EFI_GUID  gEfiPeiDelayedDispatchPpiGuid;



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109481): https://edk2.groups.io/g/devel/message/109481
Mute This Topic: https://groups.io/mt/101865809/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2023-10-10  8:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10  0:18 [edk2-devel] [PATCH v2 0/4] Implement Delayed Dispatch per PI v1.8 Kun Qin
2023-10-10  0:18 ` [edk2-devel] [PATCH v2 1/4] MdePkg: DelayedDispatch: Correct PPI descriptions Kun Qin
2023-10-10  0:18 ` [edk2-devel] [PATCH v2 2/4] MdePkg: DelayedDispatch: Added WaitOnEvent interface Kun Qin
2023-10-10  8:46   ` Laszlo Ersek [this message]
2023-10-10  0:18 ` [edk2-devel] [PATCH v2 3/4] MdeModulePkg: PeiMain: Introduce implementation of delayed dispatch Kun Qin
2023-10-10 13:14   ` Laszlo Ersek
2023-10-10  0:18 ` [edk2-devel] [PATCH v2 4/4] MdeModulePkg: PeiMain: Updated dispatcher for " Kun Qin
2023-10-11  1:48 ` 回复: [edk2-devel] [PATCH v2 0/4] Implement Delayed Dispatch per PI v1.8 gaoliming via groups.io

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f7f2772-2cd4-ffa4-2ffa-628fe18f15c7@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox