OSDev.org
https://forum.osdev.org/

Strange information in multiboot memory map
https://forum.osdev.org/viewtopic.php?f=1&t=56331		 Page 1 of 1
Author:  mrjbom [ Wed Jun 22, 2022 7:45 am ]
Post subject:  Strange information in multiboot memory map
Hello.
To view the map, I use the code taken from the multiboot specification 0.96 page
Here it is:
Code:
    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:
Attachment:
mmap qemu 128 mebibytes.png
mmap qemu 128 mebibytes.png [ 14.34 KiB | Viewed 1010 times ]

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?
Author:  iansjack [ Wed Jun 22, 2022 8:26 am ]
Post subject:  Re: Strange information in multiboot memory map
Yes.

It's address space used for MMIO, not user RAM. That's why the type is "reserved".
Author:  mrjbom [ Wed Jun 22, 2022 8:36 am ]
Post subject:  Re: Strange information in multiboot memory map
iansjack wrote:
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!
Author:  Octocontrabass [ Wed Jun 22, 2022 10:00 am ]
Post subject:  Re: Strange information in multiboot memory map
It's normal for there to be large gaps in the memory map with ordinary RAM too, not just MMIO.
Author:  mrjbom [ Wed Jun 22, 2022 3:57 pm ]
Post subject:  Re: Strange information in multiboot memory map
Octocontrabass wrote:
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.
Author:  nexos [ Fri Jun 24, 2022 4:56 am ]
Post subject:  Re: Strange information in multiboot memory map
Quote:
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
Author:  vvaltchev [ Fri Jun 24, 2022 11:01 am ]
Post subject:  Re: Strange information in multiboot memory map
nexos wrote:
Quote:
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.
Author:  davmac314 [ Fri Jun 24, 2022 7:14 pm ]
Post subject:  Re: Strange information in multiboot memory map
vvaltchev wrote:
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.
Author:  vvaltchev [ Mon Jun 27, 2022 11:36 am ]
Post subject:  Re: Strange information in multiboot memory map
davmac314 wrote:
vvaltchev wrote:
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.
Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/