public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Samer El-Haj-Mahmoud" <samer.el-haj-mahmoud@arm.com>
To: Leif Lindholm <leif@nuviainc.com>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Sami Mujawar <Sami.Mujawar@arm.com>,
	edk2-devel-groups-io <devel@edk2.groups.io>,
	Rebecca Cran <rebecca@nuviainc.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [edk2-rfc] [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64
Date: Mon, 11 Oct 2021 21:52:13 +0000	[thread overview]
Message-ID: <AM5PR0801MB171575AA030B9C98001943F690B59@AM5PR0801MB1715.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20211011150150.prd5y43ncczp7qkb@leviathan>

Hello Leif,

>
> > > But it might be good to hear something from ARM whether the use of
> this
> > > protocol which "must be produced on any system with more than one
> logical processor"
> > > *should* be able to rely on anything being set up for it, or whether we
> > > need an aforementioned helper library.
> >
> > This statement (from the PI spec) is overly ambitious. I bet that it
> > does not hold true today on most DXE-based UEFI implementations on
> > other architectures, not just AARCH64. If we agree, I will file an
> > ECR to remove this statement from the PI spec.
>
> That feels like a weird response to the submission of a patch set
> adding the functionality for AArch64.
>
Agree this comment is not directly related to the RFC, and should be directed to the UEFI Forum instead, so please ignore my comment.


> >
> > From AARCH64 SBBR systems point of view:
> >
> >   *   The requirements from Arm SBBR point of view are around using
> >       PSCI to online/offline Secondary cores, and leaving them
> >       offlined before ReadyToBoot is signaled.
>
> SBBR is not relevant here. PI covers firmware internals, not OS
> boot compatibility.
>
> >   *   PI-based UEFI implementations are not required. And even when
> >       they are implemented, the EFI_MP_SERVICES_PROTOCOL is not
> >       required
>
> So ARM's strategy is to encourage people not to us it *in* PI
> implementations, even when it is portably implemented on top of PSCI?
>
Arm does not have any PI specific requirements on platform firmware, beyond what is in the PI spec itself.  Arm's official requirements are only on OS boot interoperability (SBBR).

For the RFC itself, I personally do not have any objection, and welcome the addition of this protocol to AARCH64, as long as it utilizes the PSCI services to achieve the OS boot requirements.

It may be worth getting feedback from Sami since he is the EDK2 maintainer for Arm platforms.



> Regards,
>
> Leif
>
> >   *   I agree with the analysis in this thread. EFI_MP
> >       implementations on AARCh64 need to be severely limited in the
> >       general case. Platforms (upstream or downstream) can still
> >       innovate and write their own code to run in these services as
> >       they wish.
>
> >
> >
> > Thanks,
> > --Samer
> >
> >
> >
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

  reply	other threads:[~2021-10-11 21:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-25  2:17 [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64 Rebecca Cran
2021-09-25  2:17 ` [RFC] [PATCH 1/2] ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO struct Rebecca Cran
2021-09-25  2:17 ` [RFC] [PATCH 2/2] ArmPkg: Add Library/MpInitLib to support EFI_MP_SERVICES_PROTOCOL Rebecca Cran
2021-09-28 11:14 ` [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64 Leif Lindholm
2021-10-07  9:41   ` Leif Lindholm
2021-10-07 10:03     ` Ard Biesheuvel
2021-10-07 11:02       ` Leif Lindholm
2021-10-08 14:51         ` Ard Biesheuvel
2021-10-11 12:28           ` Leif Lindholm
2021-10-11 14:20             ` Samer El-Haj-Mahmoud
2021-10-11 15:01               ` [edk2-rfc] " Leif Lindholm
2021-10-11 21:52                 ` Samer El-Haj-Mahmoud [this message]
2021-10-14 13:14                   ` Leif Lindholm
2021-10-18  9:21                     ` Sami Mujawar
2021-10-18 11:54                       ` Leif Lindholm
2022-01-19 10:28                         ` [edk2-devel] " Sami Mujawar
2021-10-14 12:41   ` Rebecca Cran

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=AM5PR0801MB171575AA030B9C98001943F690B59@AM5PR0801MB1715.eurprd08.prod.outlook.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