> 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. Thanks, Andrew Fish > Thanks > Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
