[Freemint-discuss] Virtual Memory Implementation Ideas

[Mark D. <mdu...@at...>]

Hello all,

I've been researching virtual memory, mmu, and freemint internals.  I've 
still got a lot to read but I am starting to formulate a plan and 
overall goals.  I'm looking for comment from people smarter than I am.  
I have some ideas for milestones in terms of modifications to the memory 
protected mmu table layouts, expanding the bus error handler, etc, but I 
will keep it simple for now.

The problem - there are lots of compatibility issues with virtual memory 
and gem programs.  Many that I am not experienced enough to understand.  
Mint with memory protection works pretty well though.  This isn't 
tremendously far away from virtual memory as a concept at all.

Here is my plan.  Virtual memory will be configurable to be on or off as 
a concept.  It will require memory protection to be enabled.  You will 
be able to specify your virtual address space but I will choose 
0xbdffffff-0xfdffffff as an example.  The virtual address space may not 
collide with physical ram address space or hardware registers.

In the beginning I am thinking to carve out a physical memory slice (say 
50%) to test various page allocation mechanisms. Eventually there is no 
reason that this cannot cooperate with normal program memory allocations 
for any reason other than fragmentation.  A split system might be for 
the best?

Processes will have a new flag added to indicate whether or not they 
support virtual memory.  This is to opt in.  If they support virtual 
memory they will be able to use mman functions like mmap.  In the 
beginning it will only map empty pages to physical memory.

Then we have to add fd mapping.

Then we can load processes into virtual memory address space and demand 
page them in.

Then we can add ELF support

Then we can add shared linking.

The important thing to understand here is that processes will not have a 
free for all control over the entire address space.  They will simply 
have some part of the address space that can be virtualized.  This means 
that the lower hardware registers, tsrs, and other globals will look the 
same to vm processes and normal processes alike.  Normal non-vm 
processes cannot interact with virtual memory processes.  VM processes 
however will be able to access shared and global memory of normal 
processes.

What is the problem with this?  GEM programs for the most part do not 
use common libraries for shared libraries to be truly practical in any 
serious sense.  The benefit here is in the unix ports, their common 
dependencies, their copious memory usage and slow forking.  Apply demand 
paging and all the various benefits to those things only.  Keep 
everything else the same for compatibility.

Now the question is, what is my idea missing?  Is this viable?

PS: No promises on timelines.  I don't want to deliver anything bad into 
the kernel.  This is also my first foray into kernel programming.  Of 
course I have to pick something very complicated.  But it doesn't seem 
so complicated to me now that I live and breathe it for weeks.

Thanks,
Mark