[Fw_Os_Forum] Support for EFI MP Services

[Brett Stahlman]

Excellent! Thanks. This is apparently what I needed. I've successfully
used the DXE MP Services protocol from my OS loader. And if I
understand correctly, I should be able to use StartupThisAP and/or
StartupAllAPs to have the APs vector directly to my 64-bit Long Mode
startup code (skipping the trampoline up from Real Mode, which should
already have been performed by DXE).

Thanks for you help.
Brett S.

On Tue, Jul 19, 2016 at 4:15 PM, valerij zaporogeci <vlrzprgts at gmail.com> wrote:
> It means AP's.
> quote (Platform Initialization Specification VOLUME 2, DXE Core
> Interface, section 13.3 MP Services Protocol Overview):
> After the UEFI event ... or
> EFI_EVENT_GROUP_EXIT_BOOT_SERVICES (event) is signaled, all the APs
> must be placed in the OS compatible CPU state as defined by the UEFI
> Specification.
>
> And UEFI states it runs uniprocessor (UEFI spec 2.4, sections 2.3.2,
> IA-32 Platforms, and 2.3.4, x64 Platforms) and refers to "Intel 64 and
> IA-32 Architectures Software Developer's Manual —Volume 3, System
> Programming Guide, Part 1."
>
> And, to be honest, I never found more detailed desciption on MP
> elsewhere in UEFI spec. But I read it not completely.
> So, reading this sequence, It's very imlicitly says they, AP's, should
> be put in long mode (on x64) and wait for INIT IPI at the time of your
> bootloader gets control. You also may consult ACPI for this, since the
> description of DXE MP protocol says this:
>
> [MP Services Protocol may be consumed by ACPI module. The ACPI module
> may use this protocol to retrieve data that are needed for an MP
> platform and report them to OS.
>
> MP Services Protocol may also be used to program and configure
> processors, such as MTRR synchronization for memory space attributes
> setting in DXE Services.
>
> MP Services Protocol may be used by non-CPU DXE drivers to speed up
> platform boot by taking advantage of the processing capabilities of
> the APs, for example, using APs to help test system memory in parallel
> with other device initialization.
>
> Diagnostics applications may also use this protocol for multi-processor.]
>
>
> 2016-07-19 19:06 GMT+03:00, Brett Stahlman <brettstahlman at gmail.com>:
>> When you say PI takes CPU into "OS expected state defined by EFI",
>> which CPU(s) are you referring to? The Intel MultiProcessor
>> specification indicates that secondary processors (APs) will come up
>> in Real Mode after receiving STARTUP IPI. Is this how it's supposed to
>> work during UEFI boot, or is the PI also responsible for bringing the
>> APs up to 64-bit Long mode? To bring up secondary processors under
>> BIOS, it was necessary for the BSP to do the following:
>>
>> 1. Load 16-bit Real Mode AP initialization code someplace within the
>> 1st MiB of address space.
>> 2. Use local APIC to configure the initialization routine's address as
>> the "startup vector".
>> 3. Deliver the INIT/STARTUP IPI sequence to the AP to get it to start
>> executing the startup code.
>>
>> What I'm trying to understand is whether something like this is still
>> necessary, or whether I can expect PI to handle the AP initialization
>> for me?
>>
>> Thanks,
>> Brett S.
>>
>> On Tue, Jul 19, 2016 at 10:40 AM, valerij zaporogeci
>> <vlrzprgts at gmail.com> wrote:
>>> oh, EFI_MP_SERVICES_PROTOCOL is not a part of UEFI at all. It's a DXE
>>> "boot service" protocol. You may expect its presence only on systems
>>> implementing PI specification. The latter is not UEFI. (I believe it
>>> would be hard to say what it is even for its creators, because it
>>> claims it's a standalone standard, it's a UEFI implementation, it's
>>> not compatible superset over UEFI at the same time).
>>> And as I've understood, that protocol is not intended to bring AP's to
>>> the state needed for OS, rather it is intended to bring MP in PI (DXE)
>>> environment "for speeding up" things. Once Exit boot services related
>>> event is signaled, PI takes CPU into "OS expected state defined by
>>> EFI".
>>