shadowing page tables

[userz0]

helloz,

i read alot in l4 articles about pagers and how they can manage memory.

so far so good. i know good reasons for using l4's map&grant&unmap primitives.

but i also read in many documents about that usually every pager in l4 tries to mirror the pagetables created already in the kernel (via said low level primitives). but there is never said a reason of why i should do that, and unfortunately i can't think of any either.

so far, i also am a bit concerned about having a correct page replacement policy, when i cannot even access stuff like reference bits. i know you could artificially create pagefaults and such to simulate those, but i think it is not good.

so yeah, this is basically two questions i have:

1) why do i need page tables in user level
2) how can i implement a sufficient page replacement policy

thank you for the answers, which will hopefully come. because i seriously need help with this.

thanks again,
byez

edit: oh and sorry, i wanted to create this in another section, i must have been misclicked. topic should go in os development section.

[userz0]

1) why do i need page tables in user level

So that your pager can manipulate them? Making it accessible via IPC might be just too slow.The only privileged instruction you need is invlpg and you can use it via a protected syscall.

i'm not quite sure if i understand. there are many things not clear to me.

Making it accessible via IPC might be just too slow.

do you speak of the kernel page tables ? because my actual question was why should i recreate/shadow the already existing page tables in the kernel, as a whole new datastructure in my user/pager adress space.

So that your pager can manipulate them?

but do i need to store second page table datastructures at user level and manipulate those ? i mean i already manipulate the kernel page tables via IPC, as a result of a page fault. so why do i need user level page tables, when i can simply map/unmap and give out/withdraw memory like this.

[userz0]

hey again,

The only privileged instruction you need is invlpg and you can use it via a protected syscall.

ok, so i do not know if you did this intentionally, but now i might know a reason for having to create a second page table datastructure at user level, besides those existing already in the kernel.

this invlpg invalidates parts of of my mmu cache, so the next acess on that page creates a soft-pagefault ? therefore i would have to recheck, so that i do not map pages twice ? am i on the right path ?

[Nessphoro]

invplg -Invalidates (flushes) the translation lookaside buffer (TLB) entry specified with the source operand. The source operand is a memory address. The processor determines the page that contains that address and flushes the TLB entry for that page.

[userz0]

do i somehow have reading access to the kernel level page tables ? maybe map that part of the adress space to user level, to read them there ? because i am interested in accessing reference bits, if they are created.

There's an opposite solution possible - keep all tables in the userspace pager and only page fault handler may need to have access there.

so you would end upt with two page table datastructures, one at kernel, which is unaccessible to you as a pager (you only manipulate via IPC map/grant/unmap), and one, more or less redundant page table datastructure, just for the pager ? then my question would be why i would do it like that (that was my initial question).

invlpg is needed for flushing the TLBs in some cases where this cannot be avoided/postponed to page fault handler. See Brendan's post about this.

then why do you give me that instruction at hand.

Not really.

hm..the tlb gets flushed at an adress spac switch, right ? so i get a minor page fault, as menitioned in the wiki => http://en.wikipedia.org/wiki/Page_fault

would it then not make sense if me as a pager would have a page table for each process/task, so that i will know that some pages are still in memory, but not in the tlb anymore ? because otherwise i would only have the kernel ones, which are not readable to me.

[Combuster]

You seem to have missed on what the TLB is supposed to do. You can as userland software assume that it does not exist. The hardware operates it mostly on its own and the kernel can occasionally intervene if it does something the hardware normally does not expect.

As far as software is concerned, you only need to provide page tables that map addresses in virtual memory to addresses in physical memory, as well as the allowed operations on those areas. The processor will read these tables and discard/load parts of the TLB so that the access requested by the software can be performed. Only if the operation requested is actually invalid, a pagefault will be thrown. The secure kernel therefore usually maintains the page tables and only allows the memory manager to modify them according to some constraints of security.

The reason why invlpg exists is because the processor makes some assumptions about when pages may be changed for performance reasons. If you change permissions or remove a page from virtual memory, the TLB doesn't normally see that and will think the same access rules apply. If the kernel manages page security, then it will call invlpg when necessary. If the kernel absolutely does not care about security and lets the userland memory manager do the pagetables then it will instead have to provide an invlpg syscall so that that task can still be performed as appropriate.

[userz0]

An advantage afforded by our example pager is that information
regarding the association between a ClientPage
and the corresponding PagerPage is kept internal to the
pager in a page table data structure. The pager can then
choose any suitable page table organization.

quoted by l4 devs.

so does this mean that i should mirror the already exisiting kernel level page tables, which i manipulate of course as a response of page faults via IPC ? (with "mirror" i mean creating similar page table datastructures on my own at user land, in parallel to the kernel).

If the kernel manages page security, then it will call invlpg when necessary. If the kernel absolutely does not care about security and lets the userland memory manager do the pagetables then it will instead have to provide an invlpg syscall so that that task can still be performed as appropriate.

the kernel i use is not modified by me. it constructs the page tables via IPC as i said. so my question was, because i read that many times now, why should i recreate what is already in the kernel.

Third case, if you split kernel page tables and userspace page tables and let pager manipulate only latter will require duplicating kernel tables in the pager (because otherwise the pager will be unable to look them up), I think it is a waste to design like this.

userspace page tables and kernel page tables would both be managed by me as a pager (according to the documents i read, or maybe i misunderstand them, dont know). in fact, if i would not manipulate the kernel ones, my system would not work.

the problem is: me as a pager cannot really read the information given in kernel page tables, that would make the memory management a whole lot easier.