On Fri, Oct 8, 2021 at 3:51 PM Ard Biesheuvel <firstname.lastname@example.org> wrote:
Ok, so that doesn't look as bad as I thought. But we'll have to be
So either we severely constrain the kind of code that we permit to runThe description for StartupAllAPs() has a note:
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.
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).
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.
I think there is no way a protocol defined in the UEFI specification could
safe to use by non-BSP. In PI, the only references I find to the protocol
in MM and SAL protocols.
And we're not even looking at EFI_MP_SERVICES_PPI at this point.
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
*should* be able to rely on anything being set up for it, or whether we
need an aforementioned helper library.