On 09/09/15 19:02, Ard Biesheuvel wrote:
> On 9 September 2015 at 17:42, Andrew Fish <af...@apple.com> wrote:
>>
>> On Sep 9, 2015, at 7:03 AM, Ard Biesheuvel <ard.biesheu...@linaro.org>
>> wrote:
>>
>> On 9 September 2015 at 15:59, Laszlo Ersek <ler...@redhat.com> wrote:
>>
>> On 09/08/15 19:35, Ard Biesheuvel wrote:
>>
>> When executing on a LPAE capable 32-bit ARM platform, we support
>> up to 40 bits of physical address space so set PcdPrePiCpuMemorySize
>> accordingly.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>> ArmVirtPkg/ArmVirt.dsc.inc | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
>> index b49c1bfb8b04..c1b78be84e74 100644
>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>> @@ -371,6 +371,9 @@ [PcdsFixedAtBuild.common]
>> gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x80, 0x6d, 0x91, 0x7d,
>> 0xb1, 0x5b, 0x8c, 0x45, 0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94}
>> !endif
>>
>> +[PcdsFixedAtBuild.ARM]
>> + gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|40
>> +
>> [Components.common]
>> #
>> # Networking stack
>>
>>
>> Right, the "ArmPkg/Drivers/CpuPei/CpuPei.inf" builds the CPU HOB based
>> on this, and then the DXE core determines the size of the GCD Memory
>> Space Map's first (= "all is nonexistent") entry from that.
>>
>>
>> Indeed. Otherwise, memory above 4 GB just gets ignored, which means
>> its existence does not get advertised to the OS either.
>>
>>
>> It should get advertised to the OS, that is why the memory map is
>> EFI_PHYSICAL_ADDRESS. 32-bit x86 platforms can have a larger physical
>> address space, than virtual. This was how it was done in the past.
>>
>> Plus, you probably don't have to care about any size increase in page
>> tables that are allocated from the permanent PEI RAM (cf. SVN rev 17719).
>>
>>
>> The 1:1 mapping only goes to 4 GB, so anything beyond that is never
>> mapped anyway.
>>
>>
>> This is the state when you hand off to the OS, but it is possible as part of
>> the boot process to have a driver do some alternate mapping. This was done
>> on x86 servers for a software based memory test for example.
>>
>
> OK, thanks Andrew. I have no idea if the 32-bit ARM MMU code would
> deal with that at all (you would probably know better than I), but I
> was just trying to get my 32-bit QEMU working with > 3 GB of memory.
>
> So in patch #2, I needed to split the memory into two regions to get
> the DXE core to handle it correctly, one below 4 GB and one above 4
> GB. Is that expected?
We've recently had a long discussion about just that part of the DXE
core, here:
http://thread.gmane.org/gmane.comp.bios.edk2.devel/1023
Which is why I didn't question (or speak to) that part of your patch
(ie. the justification in the commit message).
And, OVMF does the same, re splitting low memory from high memory into
separate HOBs; what's more (as you can see in the thread linked above)
the high area is even exposed as untested memory.
Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
