Hello Leif, > > > > 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. > Agree this comment is not directly related to the RFC, and should be directed to the UEFI Forum instead, so please ignore my comment.
> > > > 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? > Arm does not have any PI specific requirements on platform firmware, beyond what is in the PI spec itself. Arm's official requirements are only on OS boot interoperability (SBBR). For the RFC itself, I personally do not have any objection, and welcome the addition of this protocol to AARCH64, as long as it utilizes the PSCI services to achieve the OS boot requirements. It may be worth getting feedback from Sami since he is the EDK2 maintainer for Arm platforms. > 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 > > > > > > 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 (#81777): https://edk2.groups.io/g/devel/message/81777 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] -=-=-=-=-=-=-=-=-=-=-=-
