public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Ni, Ray" <ray.ni@intel.com>, Achin Gupta <Achin.Gupta@arm.com>,
	 Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: Does ARM platform produce MP protocol?
Date: Wed, 6 Mar 2019 10:37:58 +0100	[thread overview]
Message-ID: <CAKv+Gu98-_5_aUW0S-yEWefD+hgdeAb4ijfBc26PomBQdC_Mpw@mail.gmail.com> (raw)
In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C060A85@SHSMSX104.ccr.corp.intel.com>

(adding Achin and Charles)

On Wed, 6 Mar 2019 at 10:16, Ni, Ray <ray.ni@intel.com> wrote:
>
> > -----Original Message-----
> > From: edk2-devel <edk2-devel-bounces@lists.01.org> On Behalf Of Ard
> > Biesheuvel
> > Sent: Wednesday, March 6, 2019 3:38 PM
> > To: Ni, Ray <ray.ni@intel.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Does ARM platform produce MP protocol?
> >
> > On Wed, 6 Mar 2019 at 06:44, Ni, Ray <ray.ni@intel.com> wrote:
> > >
> > > Ard, Leif,
> > > I am a bit interested in how ARM platform supports the MP?
> > > PI Spec defines below protocol but I failed to find a driver in ARM platform
> > producing this protocol.
> > > Or did I miss anything?
> > >
> >
> > No you are right. We don't expose that on ARM, since UEFI only runs on a
> > single core. Bringing up and taking down cores is done via a protocol called
> > PSCI, which is implemented by firmware running at a higher privilege level.
> >
> > So while it would be possible to implement the MP protocol on top of PSCI,
> > we haven't identified a use case for it yet. (The OS calls PSCI directly to boot
> > the secondary cores)
>
> Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM?
> Or will it be implemented by an ARM module?

No it is currently not implemented, and I am not aware of any plans to do so.

> I am asking this because MP_SERVICES protocol exposes CPU location information
> (Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol doesn't
> have a way to expose that information.
> If such location information isn't exposed by MM_MP, is that because ARM doesn't
> care about the location information? Or because ARM cares but forgot to add similar
> *GetProcessorInfo* interface to MM_MP when changing the PI spec?
> Or ARM doesn't use the MM_MP at all?
>

I don't know the history of this protocol and who proposed it, but
today, we don't have a need for running per-CPU initialization code in
the context of MM. Even if MM is a component of the more privileged
firmware running on an ARM system, it is running in a sandbox that was
primarily designed around exposing MM services to UEFI code running at
the same privilege level as the OS (such as the authenticated variable
store). Platform initialization code (which is more likely to require
dispatch to each core) runs in the secure world as well, but not in
the context of MM.

I will let Achin chime in here as well.


> typedef struct _EFI_MM_MP_PROTOCOL {
>         UINT32                           Revision,
>         UINT32                           Attributes,
>         EFI_MM_ GET_NUMBER_OF_PROCESSORS GetNumberOfProcessors,
>         EFI_MM_DISPATCH_PROCEDURE        DispatchProcedure,
>         EFI_MM_BROADCAST_PROCEDURE       BroadcastProcedure,
>         EFI_MM_SET_STARTUP_PROCEDURE     SetStartupProcedure,
>         EFI_CHECK_FOR_PROCEDURE          CheckOnProcedure,
>         EFI_WAIT_FOR_PROCEDURE           WaitForProcedure,
> }EFI_MM_MP_PROTOCOL;
> >
> > > typedef struct _EFI_MP_SERVICES_PROTOCOL {
> > > EFI_MP_SERVICES_GET_NUMBER_OF_PROCESSORS
> > GetNumberOfProcessors;
> > > EFI_MP_SERVICES_GET_PROCESSOR_INFO GetProcessorInfo;
> > > EFI_MP_SERVICES_STARTUP_ALL_APS StartupAllAPs;
> > > EFI_MP_SERVICES_STARTUP_THIS_AP StartupThisAP;
> > > EFI_MP_SERVICES_SWITCH_BSP SwitchBSP;
> > EFI_MP_SERVICES_ENABLEDISABLEAP
> > > EnableDisableAP; EFI_MP_SERVICES_WHOAMI WhoAmI; }
> > > EFI_MP_SERVICES_PROTOCOL;
> > >
> > > Thanks,
> > > Ray
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel


  reply	other threads:[~2019-03-06  9:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06  5:44 Does ARM platform produce MP protocol? Ni, Ray
2019-03-06  7:38 ` Ard Biesheuvel
2019-03-06  9:16   ` Ni, Ray
2019-03-06  9:37     ` Ard Biesheuvel [this message]
2019-03-06 12:41       ` Achin Gupta
2019-03-06 13:22         ` Ard Biesheuvel
2019-03-06 17:04           ` Andrew Fish
2019-03-07 11:16           ` Achin Gupta

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=CAKv+Gu98-_5_aUW0S-yEWefD+hgdeAb4ijfBc26PomBQdC_Mpw@mail.gmail.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