On Wed, Mar 06, 2019 at 02:22:25PM +0100, Ard Biesheuvel wrote:
> On Wed, 6 Mar 2019 at 13:41, Achin Gupta <achin.gu...@arm.com> wrote:
> >
> > On Wed, Mar 06, 2019 at 10:37:58AM +0100, Ard Biesheuvel wrote:
> > > (adding Achin and Charles)
> > >
> > > On Wed, 6 Mar 2019 at 10:16, Ni, Ray <ray...@intel.com> wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Ard
> > > > > Biesheuvel
> > > > > Sent: Wednesday, March 6, 2019 3:38 PM
> > > > > To: Ni, Ray <ray...@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...@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)
> >
> > IIUC, the MP protocol enables communication between processors that are
> > already
> > up instead of bringing them up or taking them down. So, it is orthogonal to
> > PSCI. Is that what you meant?
> >
>
> Surely, StartupThisAP starts up the AP, no?
I was talking about the EFI_MM_MP_PROTOCOL which I thought was the original bone
of contention.
PSCI has a direct intersection with the EFI_MP_SERVICES_PROTOCOL.
cheers,
Achin
>
> In any case, I didn't dig any deeper, but I know that PSCI can be used
> (even in the UEFI context) to execute pieces of code on another core
> (ACS uses this IIRC)
>
> > > >
> > > > 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.
> >
> > +1. There is no need to do this until UEFI runs on a single core on Arm.
> >
>
> until -> as long as ??
>
> > >
> > > > 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?
> >
> > Even if Arm used this protocol, it can work with the logical processor
> > number. I
> > don't see a need to expose the location information to the caller. It seems
> > very
> > Intel specific. Is the EFI_MP_SERVICES_PROTOCOL used on Arm?
> >
>
> No, that is what started the discussion.
>
> > > >
> > >
> > > 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.
> >
> > +1.
> >
> > I will let Charles comment on the history. Maybe this protocol was designed
> > for Arm systems where MM is the most privileged firmware. The upstream
> > implementation runs MM in the lowest privilege level. Either way, this
> > protocol
> > sense only when MM on Arm is MP capable.
> >
> > cheers,
> > Achin
> >
> >
> > >
> > >
> > > > 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
> > 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.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
