e820 non-contiguous memory map

[Izzette]

I'm using int 15h eax=e820h to obtain a high memory map before switching to 32-bit protected mode. I'm staring at the map I've received here, and find it strange that smbios in qemu has given me a set of non-contiguous memory regions, as in there is 0xf7fc0000 byte gap between two memory regions with nothing to fill it. I've confirmed this with grub2 and the Linux kernel using the same qemu flags. I know launching the program that I only have 128MiB of memory and that memory range is accounted for, but there is a 0x40000 byte region that is "reserved" outside of the physical memory I have "installed". I'm just unsure how I should have my OS interpret a non-contiguous memory map. It seems pretty easy here, as the "lonely" memory region is "reserved", but on other systems could it be marked usable and would it really be usable? I'm also curious as to why (and a little bit how, though I have some idea) my memory isn't contiguous. This is what I see (sorry I haven't implemented a serial console left so it would be a pain to copy it as text):

[SpyderTL]

If you're anything like me, and you just want to make life easy on yourself, you can ignore everything but "usable" areas, and just add those areas that are flagged as usable to your memory manager. You still have to worry a little about overlapping usable areas, but you can probably safely ignore that situation for a few years.

[Izzette]

Ok, if the BIOS says it's a usable memory region and it's non-overlapping it's actually a usable memory region, got it. As for the "why" part: that 0xfffc0000-0xffffffff region is memory mapped to hardware, right? And it actually is accessible, I could stick a pointer to it and read and/or write, it just might not be safe to do so, right?

[Korona]

This is not a phenomenon of QEMU. Real hardware has non-contiguous mapping as well. For example there is an architectural hole below 4 GiB that contains the MSI space and often the APIC and PCI BARs as well. Note that this range has to stay below 4 GiB in order to support non-64-bit aware OS.

[SpyderTL]

Ok, if the BIOS says it's a usable memory region and it's non-overlapping it's actually a usable memory region, got it. As for the "why" part: that 0xfffc0000-0xffffffff region is memory mapped to hardware, right? And it actually is accessible, I could stick a pointer to it and read and/or write, it just might not be safe to do so, right?

Yes. A region should be marked as reserved if it is being used to communicate with physical hardware, or if it contains important system data, like 16-bit interrupt handlers, SMBios code or ACPI tables. Anything the Operating System should not touch.

[Izzette]

Got it! Thanks, @SpyderTL and @Korona.