Re: Unmapping fpages

[Espen Skoglund]

[Neal H Walfield]
> We are running into a problem when the client deallocates the
> physical memory.  physmem needs to make sure that it doesn't have an
> exant mapping and it cannot trust (most) clients to do an l4_unmap.

Ask yourself: in which case does it really matter that the client does
not have read-only access to the memory (e.g., to the C library)?
Surely, the client can not modify the memory.  And if the contents of
the memory will not change (as probably is the case with a library),
there is no leakage of information anyway.  Why not just trust the
client to perform the unmap in these cases?  If it happens that one
particular client mapping needs to be revoked (e.g., due to it being a
read-write mapping), and should be revoked separately from the other
mappings, then you'll have to use some sort of alias mapping that the
server *only* maps to one client so that he can revoke this one
mapping at a later stage.

Yes, I know, the situation is not ideal.  We do, however, have ideas
on how to remedy the situation should it prove to be a real problem.

> The other problem, and the one which is far worse in my analysis, is
> that physmem cannot actually flush the 16kb fpage that it gave to
> the client: it must flush the fpage that it has because it would be
> "[p]artially unmapping an fpage [which] might or might not work"
> (idem).

The "partially unmapping" refers to established mappings.  The server
would revoke the existing mapping in the client, not in the server
itself (i.e., it would do an unmap rather than a flush).  As such,
given that the server only did a partial mapping to the client in the
first place, the "partial unmap" does not apply here.

> We could impose the requirement that memory be mapped to the proxy
> task at most once.  Thus, if 4kb of a block of memory is mapped and
> later a request (either from the same task or from a different task)
> for a 16kb map for the same block of memory which includes the 4kb
> area is requested and the 4kb area is not properly aligned in the
> proxy task, then we don't offer the 16kb but 4 4kb maps.  This,
> however, seems like a gratuitous limitation...

Why is this such a limitiation?  What do you have to gain by having an
unaligned 16KB "page" instead of 4*4KB "pages"?  For sure, you will
gain nothing in TLB coverage since the hardware will have to treat it
as 4 separate pages.  The in-kenrel page tables and the mapping
database would also have to treat it as 4 separate pages.  Your only
gain is perhaps some savings in the data structures used to implement
your memory allocation stuff.  However, since you're now dealing with
unaligned pages in these structures, the data structures themselves
and the algorithm to deal with them become more complex.

> ...and moreover would mean that we could not flush mappings on an
> per-task basis.

How does this relate to unaligned mappings?  I don't understand.

        eSk