What pages need to be fixed in the coremap?


(Muhammed Zaki Muhammed Husain Bakshi) #1

In the recitation it was mentioned that we should maintain whether a physical page is fixed or not, i.e. if a page is allocated by kernel, it should be fixed and should not be evicted.
My questions is what should be considered as kernel page. I believe the blue area in the diagram below can be considered as kernel pages and can be set as fixed during coremap initialisation.

Apart from this should we consider any page allocated while using kmalloc as kernel page. If yes then how do we differentiate if the call to alloc_kpages() is coming from kmalloc or is coming from vm_fault() when user process tries to access some memory (which should not be considered fixed).
One strategy is to consider every page we allocate inside alloc_kpages() as fixed page by default, and in vm_fault(), after allocating a page, mark it as “not fixed”. But I am not sure if this misses any other scenarios of fixed/ not fixed pages.
Thank you.


(Haneesh Reddy Poddutoori) #2

I don’t see any reason why this shouldn’t work, but you might also want to consider the scenario when a process forks and the address space is copied from the parent to child(as_copy). This is another place where you would actually be allocating a physical page to a user which wouldn’t be fixed.


(Geoffrey Challen) #3

Any page that is addressed in KSEG0 must be fixed because those addresses are not translated by the TLB: they are translated by the MMU by simply subtracting 0x80000000.

There is no real reason for your coremap to have entries that track the state of the kernel code, since those pages are never freed. You can do it this way, and some thing that it makes the math simpler (although not that much simpler), but it is also possible to set up the coremap so that it just maps memory starting with firstpaddr. See my previous post on this topic.