Invalidating mapped flexpages in pagers
paul at boddie.org.uk
Mon Mar 18 11:31:13 CET 2019
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()
> // assuming pagee_task of type L4::Cap<L4::Task>
> l4_fpage(addr_of_prev_page, L4_PAGESIZE, L4_FPAGE_RWX),
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.
More information about the l4-hackers