Mike, It‘s very good! It allows further NASM cleanup removing DB instructions. Thanks, Ray

Mike, Sounds like a good plan. Thanks, Andrew Fish

Hello, I would like to propose that we update to a newer version of NASM. https://www.nasm.us/ The most recent stable version is

Hi Leif, Please find my response inline marked [SAMI]. Regards, Sami Mujawar [SAMI] I will start reviewing this patch set. [SAMI] I can start helping with the review of the patches to start with,

Sami, any comments on this set? In fact ... we could use more help on ArmPkg in general. Would you be up for becoming an additional Maintainer or Reviewer? / Leif

This patch will also break out-of-tree platforms because it causes ArmPkg/Drivers/CpuDxe to gain a dependency on MpInitLib. -- Rebecca Cran

Hello Leif, Agree this comment is not directly related to the RFC, and should be directed to the UEFI Forum instead, so please ignore my comment. Arm does not have any PI specific requirements on

Hi Samer, Yes, I was referring to references, as in any protocols explicitly stating compatibility with being called from an AP. That feels like a weird response to the submission of a patch

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. This statement (from the PI spec) is overly ambitious. I bet that it

+Samer 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

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

This is a good point, and something we at the very least should point out more explicitly - and perhaps ought to provide a helper library to do - ... ... but I'll note that EFI_MP_SERVICES_PROTOCOL

The code changes by itself look fine to me. The only problem I see is that we cannot run arbitrary code on other cores with the MMU off, given that in that case, they don't comply with the UEFI

Ard/Sami - any comments? / Leif

Just to add to this: Aff0 was never defined by the architecture to be the "core", it was just the smallest schedulable entity. The intent being that whether you had multiple hardware threads per core

Add support for EFI_MP_SERVICES_PROTOCOL during the DXE phase under AArch64. Call PSCI_CPU_ON to power on the core, call the supplied procedure and then call PSCI_CPU_OFF to power off the

Remove the ClusterId and CoreId fields in the ARM_CORE_INFO structure in favor of a new Mpidr field. Update code in ArmPlatformPkg/PrePeiCore/MainMPCore and ArmPlatformPkg/PrePi/MainMPCore.c to use

I'd like to propose adding EFI_MP_SERVICES_PROTOCOL support for AARCH64 systems. I've attached two patches to implement support for it in the DXE phase, based on code in EmulatorPkg and UefiCpuPkg.

I would like to start a discussion regarding integration of the static analysis (SA) into the edk2 workflow. I assume the SA benefits are well understood, so I'll get straight to the point; however,

Hello Jiewen, Thanks for writing this up. As you know, ARM is a bit behind in the CCA space, and so I will not be able to take part in these discussions in great detail. I will leave it to the