New memory map structure

Antti · **Posted:** Sun Oct 25, 2015 8:27 am

Owen wrote:

But why not the UEFI memory map structure? No translation on UEFI. On non-UEFI, map the "native" format into a UEFI memory map. And if you need a type which UEFI doesn't define? Well, as said, there are 2^31 type codes reserved for arbitrary use by the OS.

Additionally, whatever part of your system sets up paging needs to make a call back into UEFI with the address map anyway. If all you have is a translated map, you're in for a world of hurt there.

It has been more than a year I started this topic. The first post did make sense back then but now I am leaning toward using this UEFI structure also on non-UEFI computers. I totally ignored the fact that on UEFI computers I would need to give the map back if I wanted to use runtime services. Having a native format described in the first post for the OS itself (to which memory maps are converted, whether they came from the UEFI or not) does not offer any significant advantages in this case. The OS will handle memory in its own internal structures so the format would have been only a transfer format. Converting "BIOS formats" to the UEFI format (with good validity checks) makes sense at this point and the "post-boot" state is uniform between the legacy and modern systems.

Owen wrote:

So why invent something new and perfect?

I did and do like the gapless memory map.

Brendan · **Posted:** Sun Oct 25, 2015 9:47 am

Hi,

Antti wrote:

Owen wrote:

But why not the UEFI memory map structure? No translation on UEFI. On non-UEFI, map the "native" format into a UEFI memory map. And if you need a type which UEFI doesn't define? Well, as said, there are 2^31 type codes reserved for arbitrary use by the OS.

Additionally, whatever part of your system sets up paging needs to make a call back into UEFI with the address map anyway. If all you have is a translated map, you're in for a world of hurt there.

It has been more than a year I started this topic. The first post did make sense back then but now I am leaning toward using this UEFI structure also on non-UEFI computers.

Somewhere in that year, I've stolen the "gapless" idea and started using it in my code. I've found it more convenient, mostly because you can insert entries without changing the previous entry's "length" field.

I've also switched from "types" to flags (e.g. one flag for RAM, one flag for volatile, one flag for faulty, one flag for hotplug, etc), and that has made things simpler and more flexible (especially when firmware reports the same area as 2 or more different types, as you can find a "safe combination" using AND/OR instead of ugly lookup tables).

Antti wrote:

I totally ignored the fact that on UEFI computers I would need to give the map back if I wanted to use runtime services.

In my opinion; you shouldn't need to use any of the UEFI run-time services after boot, and the kernel (and majority of the OS) shouldn't know or care if the firmware was BIOS or UEFI or something else. If you look at the run-time services, they're all either things that boot code can use before calling "ExitBootServices()" (e.g. getting/setting UEFI variables, getting current time), or things that would be done via. ACPI anyway (reset/shutdown), or things that no OS should be permitted to do at all (e.g. diddling with firmware updates and the massive security implications that entails, which should have only been allowed from a special UEFI application/utility). That only leaves the virtual memory services (which are pointless if you're not using run-time services).

Cheers,

Brendan

OSDev.org

New memory map structure

Who is online