Supporting Variable Length Address Spaces

[AJ]

Hi All,

I am further in to my long-mode experiences and am looking at how my paging mechanism will work. So far, I have gone for a similar system to my 32 bit os, which used a sort of fractal scheme (Last PD entry maps on to itself, thus creating 4MB of virtual memory through which new page tables can be added).

In long mode, this translates to the last PML4 entry mapping on to itself, so the PML4 is simultaneously a PML4, PD Pointer Table, PD and PT. Seems to work so far on a simulation (I will shortly be able to try it on real hardware).

In future, however, the Virtual address space support will have to include Page Map level 5 and 6 tables (when we get to full 64 bit address spaces) and I was wondering how to design my paging mechanism to cope with this. Does anyone else have an elegant solution to this? I was thinking either 1) Recompile for different CPU's (fiddly - not many people want to do this!) or 2) Have different versions of my paging function. Under this system, pagein() and pageout() will be accessed through function pointers which point to the appropriate version of the paging system.

Or does anyone have a better idea?

Cheers,
Adam

[os64dev]

I've build a class 'VirtualAddressSpace' which builds a virtual address space . One of the member functions is set which will set CR3 to the current map. By using this class you can abstract from the hardware details.

consider the function:

Code: Select all

bool mapUserSpace(u64 virt, u64 phys, u64 size);

everywhere in your code you will use this function, but when you need support for Page Map level 5 and 6 tables, you only need to change the implementation of this function and you are done.

[AJ]

I've build a class 'VirtualAddressSpace' which builds a virtual address space .

Good name

One of the member functions is set which will set CR3 to the current map. By using this class you can abstract from the hardware details.

As you probably knew given the context of your answer, I am using C++, so that's a good start! Until this point, memory management has been very much 'C-Style'. Hmm - perhaps I'll look at this class based approach. Thinking along these lines, I guess that one option would be to have a memory management base class with members that can be overriden for further 'future-proofing' while maintaining legacy addresss space too.

Thanks for the thought!
Adam