Ben: CoreInitializeMemoryServices() API tries to find the highest free memory range to initialize the DXE core. MINIMUM_INITIAL_MEMORY_SIZE specifies the minimum memory size. It first searches the resource HOB that includes PHIT and use this range as the default one, then searches other resource HOB to find the higher free memory range. Except for the first resource HOB, it will use the whole resource HOB range once its size is larger than the minimal require size. My patch still keeps this rule and tries to use the full free resource HOB range. It is simple, but not best. I agree only PhitHob EfiFreeMemoryBottom and EfiFreeMemoryTop range has no memory allocation HOB. Other range may have the allocated space. Now, there are three proposals. 1) Always use PhitHob EfiFreeMemoryBottom and EfiFreeMemoryTop range only if it is larger than MINIMUM_INITIAL_MEMORY_SIZE. 2) Simple check memory allocation hob, and choose the whole free resource HOB. 3) Full check memory allocation hob, and choose the free partial resource HOB with MINIMUM_INITIAL_MEMORY_SIZE.
My patch takes option 2. You gives option 3. I will evaluate the code change and its impact on option 3. Thanks Liming -----Original Message----- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Tuesday, August 25, 2015 6:33 PM To: Gao, Liming; Tian, Feng Cc: Kinney, Michael D; edk2-devel@lists.01.org; Laszlo Ersek; Andrew Fish Subject: Re: [edk2] Question about memory reservation from PrePi to DXE On Tue, 2015-08-25 at 06:13 +0000, Gao, Liming wrote:> Ben: > I agree this is an issue. PI spec has no limitation to create memory > allocation hob. Memory may be allocated in either the HO aprod ucer > phase memory area or other areas of present and initialized system > memory. DxeCore shouldn't assume the memory allocation hob are all > created by PEI AllocatePages() service. I attach my patch to add the > check in CoreInitializeMemoryServices(). Could you help reviewand try > first? Ok, I'll have a close look tomorrow. Your approach does mean however that if you have a single descriptor covering all of memory you will not consider it at all if it contains a single allocation Hob. In that case we should at least consider the PEI memory between free bottom/top as pointed by the PHIT as a valid fallback. My gut feeling is that overall, we need very little memory to initialize the DXE core before we can properly handle the allocation HOBs and that maybe we are trying a bit "too hard" here. We might be better off with a bit of BSS to use as initial memory (maybe set via a PCD) or maybe restricting ourselves to the free memory left by PEI as pointed by the PHIT and be done with it (ie, require that the PEI phase leaves enough free there to do that early DXE init). Otherwise, we might end up writing a really complex algorithm to try to find a chunk of free memory not covered by an allocation hob. If you really prefer going down that path, I would suggest doing as follow: - Once you have a candidate region (either after-PHIT in the PHIT -owning descriptor or another descriptor higher up) call a function to "adjust" it. That candidate region however is only as big as the min memory needed to init DXE, don't use the enitre descriptor size. - That function scans for allocation hobs. If there's a collision, try again moving your start address to the end of the allocation hob as long as you are still inside the same descriptor Rince & repeat until you have no collision. Cheers, Ben. > Limin > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Benjamin Herrenschmidt > Sent: Saturday, August 22, 2015 12:35 PM > To: Tian, Feng > Cc: Kinney, Michael D; edk2-devel@lists.01.org; Laszlo Ersek; Andrew > Fish > Subject: Re: [edk2] Question about memory reservation from PrePi to > DXE > > On Mon, 2015-08-10 at 16:18 -0700, Andrew Fish wrote: > > > Laszlo and I are not the maintainers for this code. > > https://github.com/tianocore/edk2/blob/master/Maintainers.txt < > > https://github.com/tianocore/edk2/blob/master/Maintainers.txt>; > > > > But it does feel like the assumption in the DXE Core is not implied > > by the PI Specifications. > > Hi Feng ! > > You never replied to that thread ... my problem is that the code in > CoreInitializeMemoryServices() will essentially pickup a piece of > memory out of *any* memory descriptor HOB completely ignoring the > memory allocation HOBs. > > That means that if Sec or Peim (or in my case, a special PrePei that > transfers controls to DXE from a different firmware layer) has marked > some memory as reserved via some memory allocation HOBs, there is > still a chance that this memory gets overwriten early during DXE > initialization, because CoreInitializeMemoryServices() ignores those > allocations completely to pick up the initial core memory, which it > then makes available to the allocator with CoreAddMemoryDescriptor(). > > It appears that the Gcd code is generally trying to honor the existing > allocation HOBs since later on, CoreInitializeGcdServices() will > iterate them and allocates them, but this happens after the above > initialization and some allocations do happen in between. > > Is there a non-documented (or maybe I missed the documentation) > requirement that all the Memory resource descriptor HOBs passed to DXE > have been modified to *remove* all allocated space from them to avoid > that problem or is this mainly a bug ? > > It does make the transition from a Flat Device Tree to DXE tricky, > since in the FDT world, we have on one hand the "memory" modes that > give us the regions of physical memory in the system, which would > nicely translate to memory resource descriptors, and separately we > have a reserve map which describes ranges of addresses that are > reserved, either by some firmware layer or in some cases by the HW > itself. > > Unless I missed something, while the spec allows us to match this to > memory resource descriptors and memory allocation HOBs respectively, > the DXE implementation will fail to honor such overlap properly. > > Am I correct ? > > Cheers, > Ben. > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
