OSDev.org

Few separate things:
- Pitfall was asking why 1GiB blank blocks were left in the address space, I have no idea, but possibly some implementations (MoBo impl) use it for more efficient routing of memory. Though that's just a guess, there's likely some firmware/hardware related reason. Might also be some legacy reason related to FW/HW.

- Using bitmaps for "sparse" address space (sparse meaning there's empty holes) has a few potential solutions:
--- Just create large enough bitmap to cover the entire range, wasting bits for all the range not used. Assuming 4KiB pages are represented by single bit in the bitmap and assuming 16GiB system with each GiB having an extra 1GiB empty space in between means you'd need to have a bitmap for 32GiB of address space, even though only 16GiB of RAM exists. If I did my math correctly that means 8MiB bitmap, not a huge deal. Note, I think a stack is easier, better, faster, wastes less space, etc.. I can't really think of good reasons to use bitmaps. From this you can probably guess that my suggestion to you is to use a stack, as a consequence whether the memory is totally fragmented and in pieces becomes irrelevant to you and you don't have to care.
--- Alternatively you could create multiple bitmaps, recording the start address of each, this is more complicated and given that unless you have a specific reason to use bitmaps I seriously would recommend against the extra complexity.

- "aka you assumed it was contiguous", don't assume. Remember, back in the day certain things were at certain "known" (aka special/magic) locations, those locations still need to exist, thus they become similar to holes in the memory in the sense that they don't go to the RAM.
- Are you sure your current memory map print from your PC (which still looks weird) is using proper uint64_t for the first two columns (start and length IIRC)? They seemed to have the first part (most significant) cut off, yet the last column seemed to be able to report over 32-bit values.
- You complained about "not including anything you haven't written", do you manually write your code in asm? If not did you write your own compiler? If not, then you are already using code you didn't write. The basic headers are _part_ of the compiler, you should almost never mess with them. If they produce invalid code (which I presume is your reason for not including them) then you shouldn't trust the compiler either. STL and the standard libraries are a slightly different matter. So check the cross-compiler wiki article and include the stuff it tells you to, everything else is up to you, but if you mess with the bare minimums you'll just keep shooting yourself in the foot. There's some things that are trivial, but even many of the trivial things are anything but trivial, there's almost always some tiny minutia you have to get right and trying to do that yourself isn't really a good idea _with_ osdev.
- As for why the physical memory map is not contiguous, there's no need. Nobody needs it to be. And remember, it's not all _RAM_, there's memory mapped I/O there too (aka peripheral devices), etc. And the framebuffer for video is there too, so it's just something you have to live with, with virtual memory it really doesn't matter.


Finally, it's important that you fully understand that the following four concepts are complete different:
- PAS = Physical Address Space
- PM = Physical Memory
- VAS = Virtual Address Space
- VM = Virtual Memory

With VAS and VM, the entire 4GiB (for 32-bit prot mode) VAS always exists, whether something is mapped there as backing store is completely different, but if there is, then that's called Virtual Memory.

It's the same thing with the PAS and PM, they physical address space always exists (to varying degrees, AFAIK nobody has implemented a MoBo with all 64-bit PAS, because nobody "wants" it), whether something is mapped, and if something is mapped it might not be RAM. So the PAS is not memory, it's just address space, some address might go to memory, some might go to devices, some somewhere else. You're not allowed to guess, anymore than apps are allowed to guess VAS, the OS terminates such apps.

So start thinking about them as address spaces, both physical and virtual, and that memory is just one subtype that might be mapped to particular location in the address space.

I've chosen to use a bitmap because of its simplicity. I understand it very well and it makes sense. I don't particularity fancy anything else. It just makes a lot of sense in my head.

I can go as far as taking an existing standard types header and remodeling/reshaping it to fit my style of coding. Every little space/tab and pixel matters, remember?
I wasn't talking about the IDE or tools used to build the OS, but rather about the central code itself, doesn't really matter, not thread specific.

Looks like I lived in a perfect world where everything was contiguous. Time to break that illusion. PAS != PM
VAS for the rescue. Will try to make that one as standardized and contiguous as possible. It is easier when you know what every single address of your OS contains. That is why is like contentiousness, easy to "head book-keep".

Finally after some hardcore Wiki consulting and realizing how unnecessary complicated my code was. Here is some generally large progress:

I purpose I can safely ignore the last chunk?

Are you sure you don't still have an off-by-one error in your code? Thus potentially reading zeroed out memory, which would also explain the type being zero.

As mentioned earlier, you will need to sanitize the list if you want wide range of machines to work properly, so in this case because the last one is zero bytes length you could ignore it, I think.

Supposed the first MiB was labeled free, but somewhere within the first MiB is also another region which is labeled non-free, in that case you _should_ play it safe and break the first MiB in three parts, free, non-free, free. And then just assume that the conflicting part (that was both free and non-free) is actually non-free and don't use that memory. This may lead you to not use some memory, but it's safer than doing the opposite and hoping there's nothing important there.

And lastly about "contiguous is better", be careful not to step into the trap of making things too simple. The world is complex, attempting to simplify it too much leads to trouble, and the same goes to the "virtual world" as well. In practice once you get over the "contiguous is better" you'll see that's it's really not that big of a deal, so personally I wouldn't go enforcing arbitrary (contiguous VAS) rules on even the VAS layout, but it's your OS so you're free to do anything you like =)

For instance if you plan on implementing memory mapped files then those need to be somewhere in the VAS, and quite often people put the stack at the end and heap at the beginning (to allow max growth for both), but then where do you put mmapped files? And what if you have multiple threads in the _same_ VAS, where are the stacks for each thread? If they are back to back you lose the ability to resize the stacks (except the one that's next to the unallocated middle space). One alternative is that the stacks are all in different address spaces, and each of those address spaces are mostly the same, except for the stack. That way each stack is at the very end, and the heap is fully shared. This has its own problems, mainly pointers from one stack (thread) to another won't work as they're in different VAS's (page dirs), though threads probably shouldn't share stack allocated pointers anyway.

What I'm trying to say is, don't try to make everything too simple or you might end up painting yourself in a corner. Personally I try to allow as much freedom and flexibility to the userspace as possible, so app devs can come up with new ideas.

I'll add just a small bit about stacks as opposed to bitmaps for PMM..

The stack has essentially zero memory usage if you use the stack itself to contain the PM addresses that are free. So when all the memory is free the stack's memory usage is at it's highest, but since it's all free it doesn't matter. When you use the stack you keep "cannibalizing" the stack itself too, so when all memory is needed/used, the stack consumes potentially a single 4B/8B pointer.

Unlike with a bitmap you don't need to search for anything, just pop the first address off the stack. When you free a page just push it on the stack and your done, no need to calculate anything (ie. what position in the bitmap needs to be set to free).

This is a lot faster than searching a bitmap hoping to find the next free page quickly, and I can't really think of any down side compared to a bitmap. I actually think a stack is probably even easier than a bitmap.. But to each their own they say...

I fixed it. It was such a silly mistake. Instead of displaying and then updating the memory map, I did it the other way around, actively skipping one chunk. That explains everything.
Now I think I can say it is finally done:


Complexity is sometimes good. Ensuring compatibility and stability for example. I was not specifically talking about non memory related parts of the OS. Some things just have to be complex, because they are made that way.
Take ACPI as an example, you can't make it any simpler, it is just hard by itself. I was talking about maintainability in a way that you know what caused a page fault. Having a well sorted VAS makes page faults easy to debug.
I do not plan on implementing and kind of memory mapped files or disk swapping.

Potential problem:
My PC keeps reporting (0x20FFD3000) ~8.25 GB of RAM installed while having 8 GB physically installed.

Currently there are not many reasons for me to do that. It is like reinventing the wheel, twice. I already have a very good PMM bitmap based implementation that serves the purpose.
Spending more time on implementing/fixing something that doesn't need to be fixed and works perfectly is wasteful.
Maybe in some future revisions, who knows. But for now I have to shift my focus onto more important aspect of my OS. I am behind the schedule, a lot. At least by 2 months, because you know, bugs, lots of them, an awful lot of them.
Imagine how it feels fixing broken code and bugs for 2 months. It is not pleasant. You want to do N things, you are excited about them, but your consciousness keeps telling you to build a solid foundation first. Such a struggle.

Wrt to the over 8GiB, are you sure you are counting the length's and not the "end"'s? And you should only count type 1's (free mem), not any other types which might be anything..

It seems to me you're still missing memory.. You sure you are now printing all of them?

Also, might be easier to look at them if you printed:
start --- end --- length

Hi,



I have no idea how you obtained this number.

I'd be tempted to assume that 180 KiB of RAM is "stolen" (e.g. underneath the legacy VGA area and used for SMM) and not reported; and that a 256 MiB area of something that is not RAM (e.g. a 256 MiB at 0xF00000000, that is probably reserved for APICs, HPET, firmware ROM, etc) has been included.

To report "installed RAM" to the user, you should probably use SMBIOS tables (which will also provide information about what kind of RAM). BIOS "int 0x15, eax=0xE820" (or GRUB's memory map, which is typically the same data from the same place) is not intended for this purpose (but you could do something like "sum of usable RAM and ACPI areas; rounded up to nearest 64 MiB" to get a crude guess that's probably right in a lot of cases that don't involve integrated video or ancient hardware).


Cheers,

Brendan

++combined reply++



That moment when you realize what you've screwed up and 10 additional light bulbs light up in your head.
I was actually adding up every single value I could possibly find (every single length to be more precise). That is why there was such a big number.
Now my PC tells me I have 7.93 GB of memory. I guess I can get those 0.07 GB of memory by including those ACPI Reclaimable areas.
There shouldn't be any more areas missing, that is what I get. I've done everything as Wiki suggested, shouldn't be any more problems from this point on.
I don't want to guess anything, anymore, ever. Guessing leads to more troubles that it is worth it.
SMBIOS looks very handy for other types of information too. I could totally utilize that. Every single table has a purpose, so why not use it?
One last question:
What is the highest address my PMM is supposed to be informed of? Like is it the end of the last memory chunk?
My PMM knows that every address that has not been reserved is free for use. So if the last address is 0xSomeBigNumberBiggerThanRamSize I should still make my bitmap cover that area, right?
So for instance my PMM is supposed to cover an area from 0x0 to 0xTheLastAddressGivenByMmap and I should reserve everything but type 1 and ACPI reclaimable (once all the tables have been secured) right?

Hi,



The Physical Memory Manager only needs to care about "whole pages of RAM that the OS may use" (and doesn't need to know about things like RAM that the firmware has reserved, etc; and doesn't need to know about partial pages). This means that initially you'd probably only tell it about areas reported as "usable RAM"; and then a little later on (after you've finished using/parsing ACPI tables) you'd reclaim any "ACPI reclaimable" areas (and add them to the "usable RAM" being managed by the PMM).

However there may be more than just the PMM. For the purpose of managing and tracking other hardware (MTTRs, IOMMU, areas used by PCI devices, etc) you want some kind of "Physical Address Space Manager"; and it'd be nice if this was comprehensive (covered everything that uses the physical address space) and built into (or at least associated with) some kind of "device manager" along-side the management of other resources (IO ports, IRQs). From this perspective; you could think of "device manager" as the master, and PMM as a specialised slave.

Note that the "int 0x15, eax=0xE820" memory map is extremely badly designed. It doesn't tell you any NUMA information and doesn't tell you hot-plug information (you have to parse "ACPI SRAT" table for these), doesn't really tell you the difference between "safe to use by PCI devices" and "not safe to use by PCI devices", doesn't tell you how areas correspond to devices (e.g. "addresses 0x1234567 to 0x23456789 are in the DDR3 module in motherboard slot #2"), etc. It takes a huge amount of work (gathering information from many places and merging it all together) just to get all the relevant information into a sane/usable form (for "device manager" and/or "physical address space management" purposes).



The opposite - it knows that every address that is explicitly marked as "usable RAM" is usable RAM. Areas that are not mentioned at all (and therefore not reserved) may be "free for use by PCI devices"; but they may also be "not usable by PCI" or "not even accessible due to CPU's physical address size limits" and could also be "free for use by hot-plug RAM" (and potentially become usable RAM later if someone plugs some in).


Cheers,

Brendan

I don't think I can make anything like that anytime soon. That is something very advanced. There is no need for it because there are not devices it could manage. I could work on that once I get my GUI up and running, that
would be a nice application.
PAS manager sounds like something I could pull of and maybe have a rough idea of, but there is not need for it at the moment. I just want to start working on other interesting stuff from my TODO list. One more memory management line and I will start puking. You can't really work on something for a long long long period of time, it just gets exhausting. (memory management).

I don't think it is the opposite because the definitions we use are not equal. I think I was talking about other type of reservation (1 or 0) while you thought I was talking about memory map reserved areas.

Does anybody have, even remotely, an idea why would this happen?
QEMU everything works perfectly, Virtual Box everything works perfectly, real PC everything works perfectly, Bochs page faults... Also it only reports 3 GB instead of 4, while every other machine and emulator report everything correctly. Why does it have to be so special?

Why not check why Bochs page faults? After any interrupt/exception you should have the return address on stack, where did it come from? CR2 should hold address that caused the #PF, from there figure out (work backwards) why it happened.

As for the mmap, care to show it? Also, it would be useful for you to start including useful info in your posts, if you are asking about Bochs mmap then provide said mmap, otherwise we're all just guessing.

This line causes Bochs and only Bochs to page fault:


CR2: //this address contains nothing, nothing at all, all zeros


Bochs and only Bochs memory map:


Also how am I supposed to use the address space above 4 GB when I can only use 32 bit addresses in protected mode?

Hi,



For protected mode:

• If you use "plain 32-bit paging"; you're limited to to 32-bit physical addresses (4 GiB of physical address space)
• If you use "PSE-36 paging"; you're limited to 36-bit physical addresses (64 GiB of physical address space)
• If you use PAE;
  • For old CPUs there's 36-bit physical addresses (64 GiB of physical address space)
  • For newer CPUs (those that support long mode) it supports the same physical address size as long mode (whatever CPUID reports, up to a maximum of 52 bits)

This means that (in theory) a 32-bit protected mode kernel can use up to 4096 TiB of physical address space.


Cheers,

Brendan

So I am actively wasting an entire GB of physical memory. Great! Such a great operating system to use.
What drugs were the people developing E820 smoking when they were implementing that.
I use neither of those. It would be just too much work required to implement PAE. I do not have another 3 months to implement something that I am likely to spend another month debugging and another month bug fixing.
PSE is something that I am never ever going to implement, because 4 MB pages and no 4 KB pages above 4 GB, that options doesn't exist if you ask me.
So basically 32 bit protected mode with legacy paging is useless, it doesn't allow you to use your memory because of how the memory map was designed.

Let's hypothetically think about PAE:

• Do emulators support it? QEMU, Virtual Box, Bochs
• I can physically access 64 GB of memory.
• I can virtually access 4 GB of memory. Meaning 64 GB (RAM) have to be mapped to 4 GB (virtual memory).
• How drastically will my paging structures change?
• Pages remain 4 KB right?
• How much time will it take to implement.
• Is it easy to implement if I already have a good legacy x86 paging mechanism. (please be objective)

• Also I figured out how you do these