Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64

["Rebecca Cran" <rebecca@nuviainc.com>]

On 9/28/21 5:14 AM, Leif Lindholm wrote:

> On Fri, Sep 24, 2021 at 20:17:50 -0600, Rebecca Cran wrote:
>> 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. It's added
>> under ArmPkg for now, but longer term it should probably be moved into
>> UefiCpuPkg.
>>
>> Patch 1/2 is the start of addressing the issue that the Aff0 field of
>> the MPIDR is no longer guaranteed to be the core, and should be referred
>> to in a more generic way: for example it could be the thread, with Aff1
>> being the core and Aff2 the cluster. Clearly much more work is needed
>> to fully remove that assumption.
> 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 or not, you could just use
> the affinity to determine whether
> There is also a bit in the MPIDR to indicate whether the core *had*
> multiple hardware threads.
>
> In recent processors (without any change to the architecture), ARM
> thought it would be beneficial to keep software developers on their
> toes by starting to use the hyperthreading layout even for processors
> without hyperthreading support. I.e. Aff0 is always 0 even though MT
> is 0:
> https://developer.arm.com/documentation/100798/0301/Register-descriptions/AArch64-system-registers/MPIDR-EL1--Multiprocessor-Affinity-Register--EL1
> The justification being that an SoC might contain both processors
> with and without multiple hardware threads per core.
>
> Anyway, the point is that from at least Cortex-A76 onwards, Aff0 no
> longer maps to CoreId universally, and Aff1 no longer maps to
> ClusterId, for all non-threaded implementations.
> So we need to start cleaning up this use.
> This will possibly break some out-of-tree platforms, but I figure
> we're far enough from next stable tag for that not to matter too
> much.

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


-- 
Rebecca Cran