Invalidating mapped flexpages in pagers
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 , 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
> To put it into code:
> l4_fpage(addr_in_this_task, L4_PAGESIZE, L4_FPAGE_RWX),
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
Many thanks for showing me the appropriate mechanism!
More information about the l4-hackers