Re: Questions about copy-on-write

[Sam Mason]

Neal H. Walfield wrote:
>physmem deals is what we call virtual frames.  These are different
>from normal frames in that they provide a level of indirection:
>normally, frames are addressed by their physical address.  If we were
>to do this, it would make rearranging physical rather difficult.
>
>pages need not be in memory (they may be swapped out).  Tasks provide
>the mapping between pages and frames.  (And pages may float between
>different frames as no frame is, in general, better than any other.)

Ah, that explains another (small) mystery to me - there is a
difference between pages and frames!  I'm still having difficulty in
determining which is the physical page in memory and which is the
current mapping into a tasks address space though.  The bits of the L4
manual and VMM documentation I looked at didn't seem to shed any
light on it either.

>With respect to memory protection, L4 provides the mechanisms to limit
>access to read-only or read/write, etc.  Is that what you mean?

That was kind of assumed. . .  It was more related to how tasks
initially get access to pages of memory without disturbing other task's
memory by accident (or not as the case may be).  I'm pretty sure I
understand this now though.

Marcus Brinkmann wrote:
>Sam Mason <address@hidden> wrote:
>>Is this where most of the memory protections stem from?  Tasks can't
>>ask for arbitrary pages of memory but they can ask physmem for a new
>>(otherwise unused) page of memory or they can ask for a specific page
>>of memory out of a container.
>
>Right.

Nice simple answer!

>> If that's true then I think my confusion was coming from a belief that
>> this mechanism was in L4 iself, rather then physmem.
>
>L4 only manages the page tables, and provides the first task in the
>system with all of the physical memory in a 1:1 mapping (vaddr == paddr).

That confirms it then, I did have part of physmem's role confused with
L4.

Bas Wijnen wrote:
>you will find the systemcall unmap, which revokes a mapping 
>recursively.

OK.  It also looks as though it returns information describing if the
memory has been accessed or written to.  I guess this will eventually
be pretty useful for pager implementations.

>This cannot be used, because the task didn't physically do 
>the mapping, that was only conceptually.  Only the task which did that 
>can revoke it.  And that was physmem.  So to revoke a mapping, tell 
>physmem to do it, and it'll be arranged.  :-)

Will that always be true?


Thanks everyone! I've got a few more questions, but I think it would
probably be a good idea to let my brain to mull over everything
tonight before I try and go too much further.

  Sam