Memory map alignment

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Xeno
Member
Member
Posts: 56
Joined: Tue Oct 10, 2023 7:40 pm

Memory map alignment

Post by Xeno »

Will the memory map returned by BIOS Function: INT 0x15, EAX = 0xE820 be 0x1000 aligned?

I realised this could pose an issue in my memory managment.
Octocontrabass
Member
Member
Posts: 5560
Joined: Mon Mar 25, 2013 7:01 pm

Re: Memory map alignment

Post by Octocontrabass »

No.

It also will not be sorted and it may describe regions that overlap.
Xeno
Member
Member
Posts: 56
Joined: Tue Oct 10, 2023 7:40 pm

Re: Memory map alignment

Post by Xeno »

If they overlap how can you conclude which one is valid??
Octocontrabass
Member
Member
Posts: 5560
Joined: Mon Mar 25, 2013 7:01 pm

Re: Memory map alignment

Post by Octocontrabass »

Treat the overlapped parts as whichever one has the strictest type. (For example, if a "reserved" region and a "usable" region overlap, the overlapped part is "reserved".)
Xeno
Member
Member
Posts: 56
Joined: Tue Oct 10, 2023 7:40 pm

Re: Memory map alignment

Post by Xeno »

Why does it show memory regions above what is allocated, Vbox shows 4GiB when i allocate 32MiB in settings
qemu does same but 13GiB

It is always marked as resurved though
Xeno
Member
Member
Posts: 56
Joined: Tue Oct 10, 2023 7:40 pm

Re: Memory map alignment

Post by Xeno »

It seems that I am given 2 extra entries but its also two more than I my botloaders say I have.

Here is a dump of the output from qemu running 32MiB (excluding the acpi extended field as they are all 0(i already checked)):

0 9FC00 1
9FC00 400 2
F0000 10000 2
100000 1EE0000 1
1FE0000 20000 2
--Where it keeps going even though my botloader says it stops here and after the limit in memory
FFFC0000 40000 2
FD00000000 300000000 2
Octocontrabass
Member
Member
Posts: 5560
Joined: Mon Mar 25, 2013 7:01 pm

Re: Memory map alignment

Post by Octocontrabass »

Xeno wrote:Why does it show memory regions above what is allocated
Large gaps in the memory map are normal.
Xeno wrote:It seems that I am given 2 extra entries but its also two more than I my botloaders say I have.
Why doesn't your bootloader give you those entries? You need the entire memory map.
Xeno
Member
Member
Posts: 56
Joined: Tue Oct 10, 2023 7:40 pm

Re: Memory map alignment

Post by Xeno »

Octocontrabass wrote:
Xeno wrote:Why does it show memory regions above what is allocated
Large gaps in the memory map are normal.
Xeno wrote:It seems that I am given 2 extra entries but its also two more than I my botloaders say I have.
Why doesn't your bootloader give you those entries? You need the entire memory map.
No im saying the bootloader provides them, but does not include them in the length of the list.
There is no reason for this in my boot code

Those "gaps" do not exist in ram, the system is allocated 32 MiB, 31 are usable.
Those "gaps" are MUCH larger than what is availbe
Xeno
Member
Member
Posts: 56
Joined: Tue Oct 10, 2023 7:40 pm

Re: Memory map alignment

Post by Xeno »

Octocontrabass wrote:
Xeno wrote:Why does it show memory regions above what is allocated
Large gaps in the memory map are normal./quote]

Are you saying there should be areas in physical memory that DO NOT exist?
if so am i to treat them as resurved in my memory bitmap?
Xeno
Member
Member
Posts: 56
Joined: Tue Oct 10, 2023 7:40 pm

Re: Memory map alignment

Post by Xeno »

Well I now see my issue.
Thank you
Octocontrabass
Member
Member
Posts: 5560
Joined: Mon Mar 25, 2013 7:01 pm

Re: Memory map alignment

Post by Octocontrabass »

Xeno wrote:No im saying the bootloader provides them, but does not include them in the length of the list.
Why aren't they included in the length of the list? Aren't they part of the list?
Xeno wrote:Are you saying there should be areas in physical memory that DO NOT exist?
Not that there should be, but there can be. For example, a PC with 16GB of RAM might give you a memory map with 8GB of usable memory, then an 8GB gap, then another 8GB of usable memory.
Xeno wrote:if so am i to treat them as resurved in my memory bitmap?
The gaps are not memory, so your physical memory allocator should treat them the same way it treats reserved regions. (But for other purposes, like configuring MMIO, you need to know the difference between "reserved" and "not included the memory map".)
rdos
Member
Member
Posts: 3296
Joined: Wed Oct 01, 2008 1:55 pm

Re: Memory map alignment

Post by rdos »

Xeno wrote:It seems that I am given 2 extra entries but its also two more than I my botloaders say I have.

Here is a dump of the output from qemu running 32MiB (excluding the acpi extended field as they are all 0(i already checked)):

0 9FC00 1
9FC00 400 2
F0000 10000 2
100000 1EE0000 1
1FE0000 20000 2
--Where it keeps going even though my botloader says it stops here and after the limit in memory
FFFC0000 40000 2
FD00000000 300000000 2
BIOS typically will map PCI bars and VBE linear framebuffers in high memory. With UEFI, things can be mapped above 4G, and so a 32-bit OS will need to use PAE to be able to map these. These areas can sometimes be implemented in PCI devices (PCI bars) and sometimes can be conventional RAM that is remapped. A computer with above 4G memory might remap the higher GB or so in 32-bit memory above 4G to be able to map PCI devices below 4G.

Example of usable memory in one of my new PCs I'm working on which boots with 64-bit UEFI:
0 8FFFF
100000 10FFFF
120000 120FFF
5B0000 74224FFF
76C4F000 76C4FFFF
100000000 1803FFFFF

The 2:nd and 3:rd area are due to reservations I do in the UEFI boot loader. Usable RAM then starts at 5B0000, which is after the kernel image. The kernel image is loaded between 121000 and 5AFFFF. The computer has 4G RAM, but 2G is remapped above 4G to make place for PCI devices. Actually, the CAN controller (and other PSE function) BARs are mapped at 6000000000 and above.
Post Reply