32bit OVMF - only 2GB RAM available

[belliash]

Hello,

I got a question related to 32-bit UEFI. I know it is rare, but OVMF allows to boot 32-bit OSes as well and in this case this is what I am trying to do.
I have noticed that OVMF always returns in memory map only 2GB low memory, regardless how much RAM I assign to the VM, however OVMF sees whole assigned memory in UEFI setup interface.
I realized that when I wanted to reserve some space in higher half, right after the kernel for PFN database (over 0x80000000 that is). When I reach 0x80420004 the story ends up with page fault.
When I use some lower address space, like 0x00820000, everything works just fine and it gets 2086220 KB available.

As far as I know, qemu with q35 splits low memory at 2GB, but why additional RAM is not reported by EFI memory map? When I pass 3GB to VM, I expect all of it to be available (should be fully addressable), but I got only 2GB and passing -machine max-ram-below-4g=3G to qemu does not change this situation. Is this normal behaviour? Do I miss anything in bootloader code? Any ideas?

[rdos]

My guess is that this is because some PCI devices typically needs to be mapped below 4G, as well as the linear framebuffer. So BIOS will reserve 1-2 GB of memory just below 4G for this and map some of the installed memory above 4G. Since you use a 32-bit UEFI (very uncommon in real hardware), it probably assumes you cannot handle memory above 4G, so won't return it.

I think a better approach for a 32-bit OS that want to boot with UEFI is to support booting from 64-bit UEFI. You will need a stub that switch to compatibility mode and then turns off long mode and goes into protected mode. You will need to use PAE paging if the machine has 4GB or more of memory, otherwise you won't be able to use all of it.

[belliash]

Well, actually this missing memory is reported by UEFI, but it's PhysicalAddress is beyond ULONG_PTR (0xFFFFFFFF):

Code: Select all

PhysicalAddress: 0x100000000, VirtualAddress: 0x00000000, Pages: 262144, Type: 7 (EfiConventionalMemory)

It contains 262144 pages, what gives missing 1GB of RAM (assuming 3GB assigned to VM).
However since it exceeds 0xFFFFFFFF, I think it should not be mapped, so only 2GBs are available.
Now 2 real questions:

1. Should above memory descriptor reported by EFI BootServices be mapped or not?
2. If it should be mapped - is there any specific way to do it? If it shouldn't - how OS can know it has more than 2GB of RAM to use? It should be possible to use more memory, and with PAE even more.

[MichaelPetch]

Type 7 (EFI Conventional memory) is considered free and unallocated memory. Your options would be to map that extra memory into the 32-bit virtual address space with PSE or PAE.

[Octocontrabass]

Should above memory descriptor reported by EFI BootServices be mapped or not?

Before your bootloader exits boot services, paging is disabled, so you can't access that memory.

After your bootloader exits boot services, you can do whatever you want.

If it should be mapped - is there any specific way to do it?

If you want to use that memory, you need PAE. Other than that, it's your OS, you get to decide how it works.

how OS can know it has more than 2GB of RAM to use?

It reads the memory map.

[rdos]

1. Should above memory descriptor reported by EFI BootServices be mapped or not?

I'm unsure what you mean by mapped. Obviously, it cannot be mapped if you refer to a unity mapping since it is above 4G. Your question should be if you can add it as usable memory. The answer to that depends on if you use PAE paging or not. If you don't have PAE paging in your kernel, then you cannot use this memory. The next question is how you handle it in your physical memory manager. You obviously need to support physical memory handling that can handle physical addresses above 4G. This would more or less exclude physical memory managers based on linked lists as those require all physical memory to be mapped in linear memory. You would need some sort of bitmap-oriented physical memory manager. You also need to handle all physical addresses as 64-bit.

My 32-bit kernel has a lock-free bitmap-oriented physical memory manager, and work with 128GB of RAM (probably a bit more too). It can run with both 32-bit paging and PAE paging, depending on the physical memory map and some other criteria.

[belliash]

1. Should above memory descriptor reported by EFI BootServices be mapped or not?

I'm unsure what you mean by mapped. Obviously, it cannot be mapped if you refer to a unity mapping since it is above 4G. Your question should be if you can add it as usable memory. The answer to that depends on if you use PAE paging or not. If you don't have PAE paging in your kernel, then you cannot use this memory. The next question is how you handle it in your physical memory manager. You obviously need to support physical memory handling that can handle physical addresses above 4G. This would more or less exclude physical memory managers based on linked lists as those require all physical memory to be mapped in linear memory. You would need some sort of bitmap-oriented physical memory manager. You also need to handle all physical addresses as 64-bit.

My 32-bit kernel has a lock-free bitmap-oriented physical memory manager, and work with 128GB of RAM (probably a bit more too). It can run with both 32-bit paging and PAE paging, depending on the physical memory map and some other criteria.

Yes, you are right. My question was not right. Thank you for this explanation.