OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 2:53 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Strange information in multiboot memory map
PostPosted: Wed Jun 22, 2022 7:45 am 
Offline
Member
Member
User avatar

Joined: Sun Jul 21, 2019 7:34 am
Posts: 293
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 968 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?


Top
 Profile  
 
 Post subject: Re: Strange information in multiboot memory map
PostPosted: Wed Jun 22, 2022 8:26 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Yes.

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


Top
 Profile  
 
 Post subject: Re: Strange information in multiboot memory map
PostPosted: Wed Jun 22, 2022 8:36 am 
Offline
Member
Member
User avatar

Joined: Sun Jul 21, 2019 7:34 am
Posts: 293
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!


Top
 Profile  
 
 Post subject: Re: Strange information in multiboot memory map
PostPosted: Wed Jun 22, 2022 10:00 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
It's normal for there to be large gaps in the memory map with ordinary RAM too, not just MMIO.


Top
 Profile  
 
 Post subject: Re: Strange information in multiboot memory map
PostPosted: Wed Jun 22, 2022 3:57 pm 
Offline
Member
Member
User avatar

Joined: Sun Jul 21, 2019 7:34 am
Posts: 293
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.


Top
 Profile  
 
 Post subject: Re: Strange information in multiboot memory map
PostPosted: Fri Jun 24, 2022 4:56 am 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1071
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

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Last edited by nexos on Sat Jun 25, 2022 8:19 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Strange information in multiboot memory map
PostPosted: Fri Jun 24, 2022 11:01 am 
Offline
Member
Member

Joined: Fri May 11, 2018 6:51 am
Posts: 274
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.

_________________
Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck


Top
 Profile  
 
 Post subject: Re: Strange information in multiboot memory map
PostPosted: Fri Jun 24, 2022 7:14 pm 
Offline
Member
Member

Joined: Mon Jul 05, 2021 6:57 pm
Posts: 118
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.


Top
 Profile  
 
 Post subject: Re: Strange information in multiboot memory map
PostPosted: Mon Jun 27, 2022 11:36 am 
Offline
Member
Member

Joined: Fri May 11, 2018 6:51 am
Posts: 274
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.

_________________
Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 54 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group