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?
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
