On 07/06/16 22:29, Andrew Fish wrote: > >> On Jul 6, 2016, at 1:27 PM, Laszlo Ersek <[email protected]> wrote: >> >> On 07/06/16 22:07, Andrew Fish wrote: >>> >>>> On Jul 6, 2016, at 1:02 PM, Laszlo Ersek <[email protected]> wrote: >>>> >>>> On 07/06/16 21:01, Kinney, Michael D wrote: >>>>> Laszlo, >>>>> >>>>> Yes. It is possible to use CPU MP PPI on S3 resume. >>>>> >>>>> Jeff and I have been working on some proposed changes to the >>>>> CPU DXE and CPU PEIM modules to share the MP source code in an >>>>> MP library and eliminate the code duplication between the current >>>>> DXE driver and PEIM. >>>> >>>> Sounds great! >>>> >>>>> We will review the issue you are >>>>> experiencing in the current implementation under OVMF and will >>>>> make sure OVMF works for normal and S3 resume boot paths. >>>> >>>> Thank you! >>>> >>>>> In general, we prefer to not use permanent memory allocations >>>>> for the AP wake vectors. If possible, we prefer to temporarily >>>>> "borrow" a page a memory below 1MB for the Startup IPI. >>>> >>>> The backup buffer needs to be allocated in AcpiNVS memory though, does >>>> it not? (Wherever the borrowed page is stashed temporarily should be >>>> reserved from the OS.) So maybe the startup buffer could be placed in >>>> AcpiNVS immediately. >>>> >>>> (Admittedly, these approaches might differ in how many pages need to be >>>> multiplied by NumProcessors -- I don't know.) >>>> >>> >>> Laszlo, >>> >>> On S3 all the PEI memory is in AcpiNVS so a normal allocation should >>> work? EFI_PEI_SERVICES.AllocatePages(), >>> EFI_PEI_SERVICES.AllocatePool(), and not to mention the stack. >> >> Yes, that is right. This is precisely the argument that we make in >> OVMF's PlatformPei, when we install the permanent PEI RAM -- which on >> the normal boot path was reserved as AcpiNVS -- and don't produce any >> resource descriptor HOBs. >> >> However, for the purposes of CpuMpPei, PEI's pool and page allocation >> services, and the stack, are not appropriate. CpuMpPei needs a memory >> allocation strictly below 1MB (so that the APs can be started up in real >> mode). The PEI page allocation service (unlike the similar UEFI boot >> service) doesn't seem to offer an "allocate under maximum address" >> allocation mode. (Even if it did, the permanent PEI RAM that we install >> in OVMF on the S3 resume path is entirely over 1MB.) >> >> So what CpuMpPei does at the moment is: it scans the memory resource >> descriptor HOBs for system memory, and when it finds a suitable one (one >> that has enough size under 1MB), it places the buffer there. It stashes >> the data that is originally there into a backup buffer that *is* in >> permanent PEI RAM (allocated with the PEI serives), and then uses the >> low buffer for starting up the APs. >> >> The immediate problem is that OVMF's Platform PEIM does not produce any >> resource descriptor HOBs at S3 resume, so the scanning / filtering comes >> up empty in CpuMpPei. The above method could work nicely, if: >> >> - OVMF could somehow tell CpuMpPei to forego the scan, and use a fixed >> low address instead, for the "borrow page", and >> - we could ensure that the permanent PEI RAM that OVMF installs at S3 >> resume is big enough for CpuMpPei's needs (= the backup buffer, and >> everything else I don't know about yet). >> >> In a nutshell -- and I'm sorry about the wall of text -- the PEI >> allocation services are not used because they can't guarantee memory >> under 1MB, which is needed for AP startup on x86. >> > > Laszlo, > > Sorry to confuse you I was talking about the temp buffer that is used to > restore the contents of memory under 1 MB.
Ah, I understand now. I wrote "The backup buffer needs to be allocated in AcpiNVS memory though", and you meant "... which can be achieved simply by using the PEI allocation services". Yes, you are right. What I proposed would allocate the startup buffer in AcpiNVS *in addition to* the permanent PEI RAM (which already exists in AcpiNVS). Whereas the "borrowed page" approach charges the memory demand to the permanent PEI RAM (through the backup buffer). Good point! Thanks Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
