Re: EROS/Coyotos fault handers vs l4 pager hierarchy

[Marcus Brinkmann]

At Sat, 22 Oct 2005 03:07:16 +0200,
Matthieu Lemerre <address@hidden> wrote:
> Marcus Brinkmann <address@hidden> writes:
> > At Fri, 21 Oct 2005 11:17:45 +0200,
> > Matthieu Lemerre <address@hidden> wrote:
> >> > We have established in previous emails that there tends to be a
> >> > hierarchy of pagers in L4. The root of this hierarchy is privileged
> >> > because it is the ultimate source of all pages.
> >>
> >> I don't think there is such a hierarchy in L4.
> >
> > [...]
> >
> >> What is hierarchic, though, is the mapping database of course.
> >
> 
> [...]
> 
> >
> > The mapping database is hierarchic, but it is not a concept of L4.  In
> > fact, the mapping database is internal to the kernel, it's not exposed
> > to the user at all.  
> 
> I'd like to correct myself here: what I meant by "the mapping database
> is hierarchic" was really "the tree of mappings is hierarchic".  The
> fact that the mapping database is the kernel structures which stores
> this tree wasn't my point at all.

Ok.  But the tree of mappings is actually nothing else but the
abstract representation of the mapping database, so I don't see what
difference it makes to the discussion.
 
> > It can only be modified implicitely by sending map items over IPC.
> 
> Or using unmaps with which you can delete subtrees.

Right.

> >> > There is no comparable hierarchy in EROS. A fault handler's job is
> >> >to repair a page fault or not. Once a COPY is completed, there is no
> >> >further dependency on the sender's fault handler. In EROS, the
> >> >hierarchy is a matter of storage allocation, not mapping recovery.
> >> 
> >> I really think that there is no dependency on the sender's fault
> >> handler too on L4.  You can have a system which never invokes your
> >> pager (like the system I described in my last mails).
> >
> > I think there is just a misunderstanding here.  The "sender of a page"
> > in our Hurd-on-L4 design for example is always physmem.  And any local
> > page fault (which can happen because physmem is allowed to revoke
> > mappings for internal reorganization) will be forwarded to physmem by
> > the local pager.  Thus, there is indeed a direct dependency.
> 
> Don't worry, I know how what is implemented works.  I was speaking of
> the design I came up in
> 
> http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00288.html.

Oh, right, I missed that.  Well, it's true that if the client maps
memory to the server, then the server can not depend on it, and thus
doesn't.  But clearly not the whole system can work this way: At some
point, some page fault handlers need to be invoked, and they need to
depend on some other service to handle the page fault.  Clearly,
Jonathan is talking about _those_ parts of the system.  That you can
in addition to that provide "undependable data" to processes is
"extra" and doesn't affect the argument at all.
 
> In the current Hurd on L4, physmem has two differents semantical
> roles:
> 
> -It allocates physical memory
> 
> -It acts as a third party for memory transmission.

I agree with that.  The second point is actually very big.  It
contains for example support for shared memory.

A third role is "swap paging", btw.
 
> Whenever a client wants to give some memory to (e.g.) a server, the
> semantics of the operation is: "I want to give you memory that you can
> use to serve me". The constraints on this memory gift are:
> 
> -The gift has to be revocable (the client does not want memory to be
>  used against its will)
> 
> -But this revocation must not be harmful to the receiver.

If it is harmful to the receiver or not depdends on the receivers
implementation.  The client has no influence over this.  What must be
true is that the client can not break the contract.  But the contract
contains absolutely no requirement for the client: The client can just
revoke the resource at any time.  So the server must be prepared to
deal with that.
 
> >From these observations, I can thing of two classes of solutions:
> 
> -Memory is given to and can be trusted by the receiver.  This is what
>  the Trusted Buffer Object in EROS does, or what physmem does.
>  Physmem is really a trusted third-party for memory transmission.

This is true or not true, depending on who you believe.  I know that
Neal suggested something like "pinning for short amounts of time".  I
believed from the start that this is bogus, and never changed my
opinion, with one exception: some drivers and DMA operations, in which
case "short amount of time" becomes: as long as the driver wants.

> -Memory is given to the receiver, and there is no guarantee (i.e. the
>  "gift" can be revoked at anytime).  This is what is done in general
>  in EROS (if the memory is revoked, the objects just disappear), and
>  what I think is doable on L4 e.g. for both IO and capability storage
>  (for instance with my proposal with the URL above, which I'm going to
>  complete.)

This is the only workable solution, IMO.

However, I think that your proposal (the link you give above) misses
something important.  One important operation that physmem supports is
"container_copy".  If the client maps the memory directly, the only
way of transmission is a "paranoid_memcpy".  As a consequence, sharing
memory becomes impossible.

Thanks,
Marcus