Physical memory manager and grub memory map questions
Posted: Thu Apr 01, 2021 4:39 am
So i'm planning to start soon implementing my physical memory manager, i did it couple of times in the past, so at least i kind of know what to do.
But i just discovered that there is something that looks useful when doing a PMM, the grub memory map, that says what area of the memory are free to use, or what not.
But i did a search in several os projects and looks not many of them are using it, and looking at the wiki page https://wiki.osdev.org/Detecting_Memory ... p_Via_GRUB it points toward many drawbacks of this approach (but the header of the page says also that the article is little bit biased toward certain points of view), so my question is if it worth using it or not, the effort to read and parse it is not too much, and at least provide a good starting point to initialize properly the physical memory manager, with all the unavailable area marked as it is.
Then the other question is about the bitmap, more for confirmation, actually the kernel is configured to use 2mb pages (even if in the future i'm planning to make it flexible depending on user choice), so i assume that the bitmap must take it into account, since it is returning pages, every bit will then count for 2mb instead of 4kb (of course probably the best appoach is to make the bitmap size flexible too (it shouldn't be too hard) am i right?
Another question i have is regarding accessing page tables/dir data from the kernel, so i used the recursion method in the 32bit kernel mapping the page table itself to the last element, and was planning to do something similar, but since i mapped the kernel in the higher half, the pml4 entry for it is 511 (the last element), so this prevent me from using the last element of the pml4 page dir. What i'm wondering at this point is if there is a good positioning (convention) for the recursive mapping in 64bit or i just need to improvise (i was thinking btw to use in case 509th entry or something similar to keep all kernel stuff close in the addressing space), or is there a better/simplier technique that can be used with 64 bit kernels?
But i just discovered that there is something that looks useful when doing a PMM, the grub memory map, that says what area of the memory are free to use, or what not.
But i did a search in several os projects and looks not many of them are using it, and looking at the wiki page https://wiki.osdev.org/Detecting_Memory ... p_Via_GRUB it points toward many drawbacks of this approach (but the header of the page says also that the article is little bit biased toward certain points of view), so my question is if it worth using it or not, the effort to read and parse it is not too much, and at least provide a good starting point to initialize properly the physical memory manager, with all the unavailable area marked as it is.
Then the other question is about the bitmap, more for confirmation, actually the kernel is configured to use 2mb pages (even if in the future i'm planning to make it flexible depending on user choice), so i assume that the bitmap must take it into account, since it is returning pages, every bit will then count for 2mb instead of 4kb (of course probably the best appoach is to make the bitmap size flexible too (it shouldn't be too hard) am i right?
Another question i have is regarding accessing page tables/dir data from the kernel, so i used the recursion method in the 32bit kernel mapping the page table itself to the last element, and was planning to do something similar, but since i mapped the kernel in the higher half, the pml4 entry for it is 511 (the last element), so this prevent me from using the last element of the pml4 page dir. What i'm wondering at this point is if there is a good positioning (convention) for the recursive mapping in 64bit or i just need to improvise (i was thinking btw to use in case 509th entry or something similar to keep all kernel stuff close in the addressing space), or is there a better/simplier technique that can be used with 64 bit kernels?