Strange information in multiboot memory map

[mrjbom]

Hello.
To view the map, I use the code taken from the multiboot specification 0.96 page
Here it is:

Code: Select all

    printf_("mem_lower = %uKB mem_upper = %uKB\n", mbi->mem_lower, mbi->mem_upper);
    if (((mbi->flags) & (1 << (6))))
    {
      multiboot_memory_map_t *mmap;
      
      printf_ ("mmap_addr = 0x%x, mmap_length = 0x%x\n",
              (unsigned) mbi->mmap_addr, (unsigned) mbi->mmap_length);
      for (mmap = (multiboot_memory_map_t *) mbi->mmap_addr;
           (unsigned long) mmap < mbi->mmap_addr + mbi->mmap_length;
           mmap = (multiboot_memory_map_t *) ((unsigned long) mmap
                                    + mmap->size + sizeof (mmap->size)))
        printf_ (" size = 0x%x, base_addr = 0x%x%08x,"
                " length = 0x%x%08x, type = 0x%x\n",
                (unsigned) mmap->size,
                (unsigned) (mmap->addr >> 32),
                (unsigned) (mmap->addr & 0xffffffff),
                (unsigned) (mmap->len >> 32),
                (unsigned) (mmap->len & 0xffffffff),
                (unsigned) mmap->type);
    }

I use qemu and get this mmap:

The memory size that I set in the qemu settings is 128 megabytes.
In general, the whole mmap looks correct.
However, the last entry in the map is extremely strange, base_addr = 0x0fffc0000, which exceeds the total size of qemu memory, is this possible?

[iansjack]

Yes.

It's address space used for MMIO, not user RAM. That's why the type is "reserved".

[mrjbom]

Yes.
It's address space used for MMIO, not user RAM. That's why the type is "reserved".

Okay, I get it, thanks for the answer!

[Octocontrabass]

It's normal for there to be large gaps in the memory map with ordinary RAM too, not just MMIO.

[mrjbom]

It's normal for there to be large gaps in the memory map with ordinary RAM too, not just MMIO.

I know that this happens on real machines and it is affected by the physical location of the RAM blocks, but I was not ready for this on the emulator.

[nexos]

I know that this happens on real machines and it is affected by the physical location of the RAM blocks, but I was not ready for this on the emulator.

Remember: MMIO is not in physical memory. That last region of your memory map is technically not backed by any RAM, but rather is backed by device's registers (APICs, ROM, PCI BARs, etc). Think of it like VGA text mode memory at 0xB8000. When you write there, you are writing to the VGA controller's RAM, not to motherboard main RAM.

EDIT: clarify usage of term "physical memory" in last paragraph

[vvaltchev]

I know that this happens on real machines and it is affected by the physical location of the RAM blocks, but I was not ready for this on the emulator.

Remember: MMIO is not in physical memory. That last region of your memory map is technically not backed by any RAM, but rather is backed by device's registers (APICs, ROM, PCI BARs, etc). Think of it like VGA text mode memory at 0xB8000. When you write there, you are writing to the VGA controller's RAM, not to physical memory.

Yep, absolutely correct. Let me re-phrase that in one more way. The "physical" memory is not physical at all. It's just what the virtual memory maps to. The actual RAM itself is mapped to the "physical" memory at boot by the firmware. Since HW devices are mapped onto the "physical" memory, there are mem ranges where you can access devices and ranges where you access physical banks of RAM.

[davmac314]

The actual RAM itself is mapped to the "physical" memory at boot by the firmware. Since HW devices are mapped onto the "physical" memory, there are mem ranges where you can access devices and ranges where you access physical banks of RAM.

I think I know what you are saying, but I don't think it's linguistically correct and I worry that it might confuse others. I'd perhaps say that HW devices are mapped into the physical address space, not that they are mapped onto the "physical" memory. They are not mapped onto memory.

[vvaltchev]

The actual RAM itself is mapped to the "physical" memory at boot by the firmware. Since HW devices are mapped onto the "physical" memory, there are mem ranges where you can access devices and ranges where you access physical banks of RAM.

I think I know what you are saying, but I don't think it's linguistically correct and I worry that it might confuse others. I'd perhaps say that HW devices are mapped into the physical address space, not that they are mapped onto the "physical" memory. They are not mapped onto memory.

Agreed. Physical address space is the correct term. I used physical "memory" because it's shorter and more often used while speaking with kernel devs.