Hi Samer, On Mon, Oct 11, 2021 at 14:20:17 +0000, Samer El-Haj-Mahmoud wrote: > > 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.
Yes, I was referring to references, as in any protocols explicitly stating compatibility with being called from an AP. > > 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. That feels like a weird response to the submission of a patch set adding the functionality for AArch64. > > 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. SBBR is not relevant here. PI covers firmware internals, not OS boot compatibility. > * PI-based UEFI implementations are not required. And even when > they are implemented, the EFI_MP_SERVICES_PROTOCOL is not > required So ARM's strategy is to encourage people not to us it *in* PI implementations, even when it is portably implemented on top of PSCI? Regards, Leif > * 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 > > > > From: Leif Lindholm <l...@nuviainc.com> > Sent: Monday, October 11, 2021 8:28 AM > To: Ard Biesheuvel <a...@kernel.org>; Samer El-Haj-Mahmoud > <samer.el-haj-mahm...@arm.com> > Cc: Ard Biesheuvel <ardb+tianoc...@kernel.org>; Sami Mujawar > <sami.muja...@arm.com>; edk2-devel-groups-io <devel@edk2.groups.io>; Rebecca > Cran <rebe...@nuviainc.com>; Gerd Hoffmann <kra...@redhat.com>; edk2 RFC list > <r...@edk2.groups.io> > Subject: Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL > support for AARCH64 > > +Samer > > On Fri, Oct 8, 2021 at 3:51 PM Ard Biesheuvel > <a...@kernel.org<mailto:a...@kernel.org>> wrote: > > > 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. > > I think there is no way a protocol defined in the UEFI specification could be > safe to use by non-BSP. 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. > > 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. > > / > Leif > > 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. > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#81752): https://edk2.groups.io/g/devel/message/81752 Mute This Topic: https://groups.io/mt/86239012/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
