Invalidating mapped flexpages in pagers

Paul Boddie paul at boddie.org.uk
Mon Mar 18 17:09:02 CET 2019


On Monday 18. March 2019 13.38.36 Philipp Eppelt wrote:
> 
> Actually, there is a unmap flag which allows you to unmap all child
> mappings of a memory fpage. So assume you have three address spaces, A,
> B, and C, and A maps a page FP to B as FP' and B maps FP' to C as FP".
> 
> So if B decides to call unmap on its own mapping FP' with
> L4_FP_OTHER_SPACES [0], it will just unmap FP" in C's address space.
> If A decides to call `L4Re::Env::env()->task()->unmap(FP,
> L4_FP_OTHER_SPACES)` it will unmap FP' in B and FP" in C.

This seems to be exactly what I am looking for. I want the pager to hold on to 
its own mapping whilst invalidating the mapping given to its client.

> I suppose that's the way for your pager to eliminate the mapping in its
> pagee.
> 
> To put it into code:
> L4Re::Env::env()->task()->unmap(
>   l4_fpage(addr_in_this_task, L4_PAGESIZE, L4_FPAGE_RWX),
>   L4_FP_OTHER_SPACES);

Or as I did it:

l4_task_unmap(L4RE_THIS_TASK_CAP, _fpage, L4_FP_OTHER_SPACES);

Where _fpage is the previously-issued flexpage. After this, the new flexpage 
item is sent as a response to the map request.

And this works just as I had hoped: as the task traverses the pages in the 
dataspace, it causes page faults regardless of whether it has seen those pages 
before.

Many thanks for showing me the appropriate mechanism!

Paul

> [0]
> http://l4re.org/doc/group__l4__task__api.html#ga3c24e67b976870a3e911c43c8338
> 2f66




More information about the l4-hackers mailing list