Re: Invalidating mapped flexpages in pagers

Philipp Eppelt <[email protected]>
Newsgroups gmane.comp.micro-kernel.l4.devel
Message-ID <[email protected]>
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
> [email protected]
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
> 

-- 
[email protected] - Tel. 0351-41 883 221
http://www.kernkonzept.com

Kernkonzept GmbH.  Sitz: Dresden.  Amtsgericht Dresden, HRB 31129.
Geschäftsführer: Dr.-Ing. Michael Hohmuth

_______________________________________________
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.