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