Invalidating mapped flexpages in pagers
Philipp Eppelt
philipp.eppelt at kernkonzept.com
Mon Mar 18 08:35:56 CET 2019
Hi Paul,
AFAIK, you cannot unmap a page during a page fault reply. 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);
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.
Cheers,
Philipp
On 3/17/19 4:44 PM, Paul Boddie wrote:
> Hello,
>
> I have been trying to implement a pager in L4Re where the pager employs a
> memory region of limited size to satisfy map requests for a dataspace
> occupying a larger virtual memory region. Upon receiving a map request, the
> pager identifies the dimensions of the flexpage to be sent to the task
> experiencing the page fault, and it populates the flexpage's memory with the
> appropriate data.
>
> What this accomplishes so far is that when page faults occur in a task
> accessing the dataspace, mappings from virtual memory addresses are
> established in the task referring to the memory region populated by the pager.
> The task can read from page to page and keep getting new data.
>
> However, as each new map request comes in, I want to be able to invalidate the
> mappings previously made by the pager. Otherwise, I get many pages in the
> task's address space referring to the same memory, which is obviously not what
> I intend.
>
> Is it possible to send a flexpage from the pager in such a way that the
> mappings previously established by Fiasco.OC for the memory region are
> invalidated? Or have I missed some other mechanism for achieving what I am
> attempting? The L4Re documentation isn't helping me so much here, and I can't
> seem to find examples of this kind of thing in the source distribution.
>
> Thanks for any help anyone can give!
>
> Paul
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
--
philipp.eppelt at kernkonzept.com - Tel. 0351-41 883 221
http://www.kernkonzept.com
Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129.
Geschäftsführer: Dr.-Ing. Michael Hohmuth
More information about the l4-hackers
mailing list