Invalidating mapped flexpages in pagers

[Paul Boddie]

On Monday 18. March 2019 08.35.56 Philipp Eppelt wrote:
> 
> AFAIK, you cannot unmap a page during a page fault reply.

I had looked into this and couldn't see a way of returning items that would 
provide the necessary information for unmapping previously mapped pages. I 
imagine that one could specify a flexpage with an appropriate base address and 
size, but then it isn't clear how its invalidation would be communicated.

I looked at the kernel code somewhat to see how it processes map items, but it 
also wasn't clear how such items might be able to cause unmapping.

> However, your pager can track the pages you mapped and call task->unmap()
> explicitly.
> 
> E.g.
> // assuming pagee_task of type L4::Cap<L4::Task>
> pagee_task->unmap(
>   l4_fpage(addr_of_prev_page, L4_PAGESIZE, L4_FPAGE_RWX),
>   L4_FP_ALL_SPACES);

I guess that the pager needs to know the identity of the task for which it is 
performing paging. As far as I understand it, this information isn't 
automatically available via the normal IPC interactions because it would 
expose the sender to potentially undesirable operations (such as the one being 
described) purely because it communicated with another task.

So, I imagine that the task must first provide its identity to the pager 
before paging begins. Then, any unmapping can take place as necessary.

> Note, that unmap operations are expensive, especially on multicore CPUs.
> To reduce the overhead you can call unmap_batch and provide an array of
> flex-pages. E.g. if you have a set of five pages to map, you can call
> unmap_batch on the first four pages when mapping the fifth.

Thanks for the advice, Philipp! I did wonder whether this problem might have 
been solved within L4Re already but found nothing obvious (to me), and yet I 
would have thought that multiplexing access to a larger resource via a fixed 
set of pages would have been a familiar scenario.

Paul