Re: physmem, simple containers

[Marcus Brinkmann]

On Thu, Jan 22, 2004 at 11:18:59PM +0100, Niels Möller wrote:
> This capability should then be used to ask physmem to map the memory
> to wortel, which can then map it into the new task server process at
> the right location. Win: (i) Physmem owns the memory. (ii) We don't
> have to copy it. (Actually, we might not need to copy the physmem
> image to the right address either, shouldn't it be enough to to use a
> different snd base in the grant items when responding to physmem's
> page faults? Or is it important that physmem's address space is a
> one-to-one mapping of the physical memory?)

Well, physmem needs to have a mapping for all virtual memory that is
available to this system (note that if you want to run multiple "virtual
machines" in parallel, eventually you might want to insert a manager OS at
the wortel level, and thus only map a part of the actual physical memory to
physmem).  This entails that physmem needs to map in all physical memory
into its virtual address space.  It's just most convenient to do this 1:1
for two reasons.  First, it avoids all problems of reordering the memory to
fit it into physmem's available virtual memory.  Second, if any
fragmentation occurs, this fragmentation is equal to the actual physical
fragmentation.  So this is already the ideal case.  It does not give any
advantage to run physmem on virtual memory that is not a 1:1 mapping of
the physical memory.

To put it the other way: If you want to map the physmem object data into 
physmem's
address space at the load address, you have to answer where you want to map
in the physical memory at the load address (if any) to.  You could map it
into the place the physmem object data resides in physically.  But then you
have to inform physmem about it, because it must then not think of that area
as a contiguous region usable for superpages, for example.  Either way you
look at it, there is no gain.

> Anyway, a missing piece is the actual management of containers in
> physmem.

Not going into that, as I am lacking the picture here, too.
Note that we want these container objects everywhere in the system, so the
actual requirements are high.

It makes sense to hack something that works into the existing code base to
get up and running, and ignore the container concept almost completely. 
This is what I was going to do anyway.  Eventually we can then rework that
to use the canonical interfaces whatever they will be.

> I think it would make sense to split wortel in two threads, one server
> thread that serves WORTEL_MSG_* requests and page faults (I suspect
> the current arrangement won't work if physmem calls wortel before it
> has touched all its memory)

wortel maps all of physmem's memory into the physmem task at the first page
fault that automatically arises when the first instruction is executed. 
Wortel does not serve any page fault requests after that.  Look at the
execution flow in the source code.  It's mostly linear (the only reason we
have a server loop is to catch out-of-line events like debug messages).

> , and it seems even more necessary if wortel
> is to make mmap-related calls to physmem.

No way!  The order is fixed: wortel creates physmem, physmem page faults,
wortel maps all physmem memory into physmem, physmem runs and requests all
physical memory from wortel.  After it got all physical memory, wortel will
serve one more such request to indicate that the previous memory area was the
last one (nilpage).  After that the capabilities will be created, etc etc.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/