Re: [edk2] Reserved memory regions.

Subject: Re: [edk2] Reserved memory regions.

From: Mike Maslenkin <mihailm@parallels.com>

To: <edk2-devel@lists.sourceforge.net>

Date: 2014-03-06 11:30:09

I beg your pardon - I just realized that assert existed:
ConvertPages: failed to find range
AllocatePages fail - Not Found!

I forgot to substract base address from a system memory size:  
 BuildResourceDescriptorHob (
    EFI_RESOURCE_SYSTEM_MEMORY,
    EFI_RESOURCE_ATTRIBUTE_PRESENT |
    EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
    EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
    EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
    EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
    EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
    EFI_RESOURCE_ATTRIBUTE_TESTED,
    BASE_1MB, 
should be
    LowerMemorySize - ReservedMemorySize - SIZE_1MB)
    );

This is actually wrapper AddMemoryRangeHob() does in Ovmf .

So, Andrew's suggestion is a better solution.
I've looked to DuetBdsLib's UpdateMemoryMap() before and coudln't figure
out
why it was done so complex.

Thank you for pointing me.

On Tue, 2014-03-04 at 15:45 +0400, Mike Maslenkin wrote:
> No. I do not get any asserts in this case.
> Since I call AllocPages with AllocateAddress parameter, I see
> CoreAllocPages just call CoreConvertPages. And then CoreAddRange is
> called as result.
> 
> On Tue, 2014-03-04 at 01:25 +0000, Chu, Simon wrote:
> > Hi Mike,
> > In my experience, AllocatePages only can allocate the memory with EFI_RESOURCE_SYSTEM_MEMORY type.  Don't you get any alert when using AllocatePages to allocate the memory with EFI_RESOURCE_MEMORY_RESERVED type?
> > 
> > Thanks,
> > Simon Chu
> > 
> > -----Original Message-----
> > From: Mike Maslenkin [mailto:mihailm@parallels.com] 
> > Sent: Tuesday, March 04, 2014 4:59 AM
> > To: edk2-devel@lists.sourceforge.net
> > Subject: [edk2] Reserved memory regions.
> > 
> > Hello!
> > Could someone correct my understanding of reserved memory regions?
> > I want to reserve some region (below 4G) but this region must be accessible for OS.
> > To be clear this is ACPI NVS region which must be accessible for Linux Kernel, i.e request_mem_region() must succeed. 
> > So what I am doing:
> > On PEI phase I create two HOBs:
> >  BuildResourceDescriptorHob (
> >    EFI_RESOURCE_SYSTEM_MEMORY,
> >    EFI_RESOURCE_ATTRIBUTE_PRESENT |
> >    EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
> >    EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
> >    EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
> >    EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
> >    EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
> >    EFI_RESOURCE_ATTRIBUTE_TESTED,
> >    BASE_1MB, 
> >    LowerMemorySize - ReservedMemorySize)
> >    );
> > 
> >  BuildResourceDescriptorHob (
> >    EFI_RESOURCE_MEMORY_RESERVED,
> >    EFI_RESOURCE_ATTRIBUTE_PRESENT     |
> >    EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
> >    EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
> >    EFI_RESOURCE_ATTRIBUTE_TESTED,
> >    ReservedMemoryBase,
> >    ReservedMemorySize
> >  );
> > 
> > So, DXE phase will not use reserved memory.
> > To insert this reserved memory region to EFI memory map I call
> >   gBS->AllocatePages (
> >          AllocateAddress,
> >          EfiACPIMemoryNVS,
> >          EFI_SIZE_TO_PAGES (ReservedMemorySize),
> >          ReservedMemoryBase
> >          );
> > So, everyone is happy, OS kernels (Linux, Windows) successfully maps this memory.
> > But CSM LegacyBiosDxe asserts.
> > LegacyBiosBuildE820 function detects overlapped memory region, because it processes EFI memory map and HOB list during E820 map building.
> > AllocatePages() adds this region to memory map, while HOB list still contains it also.
> > So here is a question: Am I reserve memory region correctly or there is a some inaccuracy at LegacyBiosDxe?
> > 
> > 
> > ------------------------------------------------------------------------------
> > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> > With Perforce, you get hassle-free workflows. Merge that actually works. 
> > Faster operations. Version large binaries.  Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce.
> > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> > With Perforce, you get hassle-free workflows. Merge that actually works. 
> > Faster operations. Version large binaries.  Built-in WAN optimization and the
> > freedom to use Git, Perforce or both. Make the move to Perforce.
> > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
> 



------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel