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