From brettstahlman at gmail.com Tue Jul 19 10:51:11 2016 From: brettstahlman at gmail.com (Brett Stahlman) Date: Tue, 19 Jul 2016 09:51:11 -0500 Subject: [Fw_Os_Forum] Support for EFI MP Services In-Reply-To: References: Message-ID: Acan, Yes. The PI MP Service Protocol is the one I was using originally, but I did find the EFI_MP_SERVICES_PROTOCOL you mentioned. Unfortunately, BS->LocateProtocol returns EFI_NOT_FOUND for that one as well; however, I'm running under VMware ESXi, and I'm wondering whether the lack of support could be due to ESXi's incomplete implementation of the UEFI spec. Do modern desktop systems typically support this protocol? Question: Is support for EFI_MP_SERVICES_PROTOCOL mandatory for firmware that claims to support certain versions of the UEFI spec, or is it always optional? Thanks, Brett S. On Mon, Jul 18, 2016 at 9:31 PM, Chen, Ming (Acan, DTD-SH) wrote: > Hi Brett, > > So the MP Service Protocol you have tried to locate is the (PI) MP Service Protocol, {0x3fdda605, 0xa76e, 0x4f46, {0xad, 0x29, 0x12, 0xf4, 0x53, 0x1b, 0x3d, 0x08}? > > From my understanding, the Framework MP Service Protocol should only exist in old systems. Below wiki have the GUID and interface definitions: > http://wiki.phoenix.com/wiki/index.php/EFI_MP_SERVICES_PROTOCOL > > > Thanks, > Acan > > -----Original Message----- > From: Brett Stahlman [mailto:brettstahlman at gmail.com] > Sent: Monday, July 18, 2016 10:16 PM > To: Chen, Ming (Acan, DTD-SH) > Cc: fw_os_forum at mailman.uefi.org > Subject: Re: [Fw_Os_Forum] Support for EFI MP Services > > Acan, > Can you point me to the GUID for the Framework MP Service Protocol? So far, I've seen only this one: > > #define EFI_MP_SERVICES_PPI_GUID \ > {0xee16160a, 0xe8be, 0x47a6,\ > {0x82, 0xa, 0xc6, 0x90, 0xd, 0xb0, 0x25, 0xa } } > > Thanks, > Brett S. > > On Sun, Jul 17, 2016 at 8:34 PM, Chen, Ming (Acan, DTD-SH) wrote: >> Hi Brett, >> >> Just mention that there are two MP Service protocols: Framework MP Service Protocol, and (PI) MP Service Protocol. >> Note sure if you have tried both when you BS->LocateProtocol()? >> >> >> Thanks, >> Acan >> >> -----Original Message----- >> From: fw_os_forum-bounces at mailman.uefi.org >> [mailto:fw_os_forum-bounces at mailman.uefi.org] On Behalf Of Brett >> Stahlman >> Sent: Saturday, July 16, 2016 3:27 AM >> To: fw_os_forum at mailman.uefi.org >> Subject: Re: [Fw_Os_Forum] Support for EFI MP Services >> >> Aaron, >> So methods like GetNumberOfProcessors and StartupAllAPs (documented >> here >> http://www.uefi.org/sites/default/files/resources/Plugfest_Multiproces >> sing-with_UEFI-McDaniel.pdf) are not meant to be called from a boot >> loader using Boot Services? >> >> I will have a look at the other references. Hopefully the firmware's AP initialization obviates the need for some of the tedious, low-level real mode trampoline code I've seen in the kernel and other loader code performing AP bring up... If UEFI simplifies only the BSP side of things, it doesn't seem a very complete solution... >> >> Thanks, >> Brett S. >> >> On Fri, Jul 15, 2016 at 11:28 AM, wrote: >>> Hi Brett, >>> >>>>>1. Is there a way to add support for MP Services to firmware that >>>>>doesn't have it natively? Is there a list somewhere documenting >>>>>which firmware supports? >>> If you platform doesn't support the MP services protocol, chances are >>> that your platform is not compliant with the Platform Initialization >>> specification. Additionally, the PI specification defines protocols >>> that are intended for use by the firmware, not by boot loaders or the >>> OS. I would highly recommend that your boot loader only use protocols >>> that are defined in the UEFI specification. >> >> >>> >>>>>2. What is the best way to bring up the APs in an environment that >>>>>doesn't support the MP Services Protocol? I've read something that >>>>>suggests it might be easier with UEFI than with BIOS because the PI >>>>>firmware does some pre-initialization of the APs even before >>>>>handoff to the BSP - but I haven't found much documentation on this... >>> X86/X86_64 operating systems follow intel's multi processor >>> specification for waking APs when they are given control. >>> (http://download.intel.com/design/archives/processors/pro/docs/242016 >>> 0 >>> 6.pdf) All firmware (even legacy BIOSes) would initialize all >>> processors in the system, and then would either halt the APs, or put >>> the APs into a spin loop and only leave the BSP (boot strap >>> processor) running when giving control to a bootloader. >>> >>> For more information, you can refer to >>> http://wiki.osdev.org/Symmetric_Multiprocessing, or you can check out >>> how the linux kernel performs multi processor bring up. >>> >>> -Aaron >>> >>> >>> >>> >>> >>> >>> From: Brett Stahlman >>> To: fw_os_forum at mailman.uefi.org >>> Date: 07/15/2016 09:11 AM >>> Subject: [Fw_Os_Forum] Support for EFI MP Services >>> Sent by: fw_os_forum-bounces at mailman.uefi.org >>> ________________________________ >>> >>> >>> >>> I'm working on an x86_64 UEFI boot loader that runs on the BSP in >>> 64-bit long mode, and must bring up APs (secondary processors) after >>> some preliminary initialization. I've seen some documentation on EFI >>> MP (multi-processor) Service Protocol, but the headers in gnu-efi >>> don't appear to support it, and BS->LocateProtocol() reports status >>> 14 (EFI_NOT_FOUND). My questions are... >>> >>> 1. Is there a way to add support for MP Services to firmware that >>> doesn't have it natively? Is there a list somewhere documenting which >>> firmware supports? >>> 2. What is the best way to bring up the APs in an environment that >>> doesn't support the MP Services Protocol? I've read something that >>> suggests it might be easier with UEFI than with BIOS because the PI >>> firmware does some pre-initialization of the APs even before handoff >>> to the BSP - but I haven't found much documentation on this... >>> >>> Any help would be greatly appreciated. >>> Thanks, >>> Brett S. >> _______________________________________________ >> Fw_os_forum mailing list >> Fw_os_forum at mailman.uefi.org >> http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum From brettstahlman at gmail.com Tue Jul 19 12:06:00 2016 From: brettstahlman at gmail.com (Brett Stahlman) Date: Tue, 19 Jul 2016 11:06:00 -0500 Subject: [Fw_Os_Forum] Support for EFI MP Services In-Reply-To: References: Message-ID: 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 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". From brettstahlman at gmail.com Tue Jul 19 18:57:05 2016 From: brettstahlman at gmail.com (Brett Stahlman) Date: Tue, 19 Jul 2016 17:57:05 -0500 Subject: [Fw_Os_Forum] Support for EFI MP Services In-Reply-To: References: Message-ID: 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 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 : >> 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 >> 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". >>