> In PI, the only references I find to the protocol are in MM and SAL protocols.

> And we're not even looking at EFI_MP_SERVICES_PPI at this point.

 

The PI 1.7 spec defined the EFI_MP_SERVICES_PROTOCOL in page 2-180, with the PPI and MM versions in 1-193 and 4-57 respectively.

 

 

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

 

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.
• PI-based UEFI implementations are not required. And even when they are implemented, the EFI_MP_SERVICES_PROTOCOL is not required
• 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

 

 

 

 

 

> > So either we severely constrain the kind of code that we permit to run
> > on other cores, or we enable the MMU and caches on each core as it
> > comes out of reset, as well as do any other CPU specific
> > initialization that we do for the primary core as well.
>
> The description for StartupAllAPs() has a note:
> It is the responsibility of the consumer of the
> EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() to make sure that the nature
> of the code that is executed on the BSP and the dispatched APs is well
> controlled. The MP Services Protocol does not guarantee that the
> Procedure function is MP-safe. Hence, the tasks that can be run in
> parallel are limited to certain independent tasks and well-controlled
> exclusive code. EFI services and protocols may not be called by APs
> unless otherwise specified.
>
> So I think this is actually fine, implementation-wise. *Except* for
> the SwitchBSP function (where we're currently bailing out anyway).

Ok, so that doesn't look as bad as I thought. But we'll have to be
more strict than other arches: even EFI services and protocols that
are marked as safe for execution under this MP protocol are likely to
explode if they rely on CopyMem() or SetMem() for in/outputs that are
not a multiple of 8 bytes in case the platform uses the
BaseMemoryLibOptDxe flavour of this library, since it relies heavily
on deliberately misaligned loads and stores.