The classic paper on dealing with paging without access to reference bits is:
“Converting a swap-based system to do paging in an architecture lacking page-referenced bits”
http://dl.acm.org/citation.cfm?id=806595
Note: Basically, hardware dirty/reference bits are really only a performance optimisation.
You still have to implement page-based virtual memory on top of seL4, i.e. something that provides virtual memory and paging to external storage, for whatever your applications are, etc….
Given an implementation of page-based virtual memory (and a replacement algorithm such as “2nd chance clock”), the difference between having access to hardware bits and simulating bits is pretty minor.
We can look into supporting querying the hardware bits, but lack of access to them is not preventing building a specific system due to ease of emulation.
- Kevin
From: Devel [mailto:devel-bounces@sel4.systems]
On Behalf Of Raymond Jennings
Sent: Friday, 14 August 2015 7:21 AM
To: Adrian Danis <Adrian.Danis@nicta.com.au>
Cc: devel@sel4.systems
Subject: Re: [seL4] Detecting dirty/accessed page tables
So to be specific on the whole accessed/dirty bit topic.
My first intention was to ask how to do it presently, if possible.
When I found out it wasn't...I'd like to make it a suggestion for a future version.
I'm brand new to this list, so is this the proper way to make suggetions?
On Thu, Aug 13, 2015 at 1:47 PM, Raymond Jennings <shentino@gmail.com> wrote:
On Thu, Aug 13, 2015 at 5:48 AM, Adrian Danis <adrian.danis@nicta.com.au> wrote:
Currently there is no support in seL4 for taking advantage of hardware support for detecting dirty/accessed pages. If you want this then you must emulate this in software by changing the access writes on pages and handling the resulting page faults.
The reason for not supporting any underlying hardware features for this is the original, and verified, platform that seL4 was written, an armv6, did not have hardware support for tracking this.
Since porting seL4 to x86 and newer ARM architectures that have support for this there has not been any perceived need for this, so it has not been done. There is certainly no reason requesting such information could not be done within the capability model.
This is why I was asking if having mapping rights on the page descriptor/page table would be sufficient. If you can change which physical page a virtual address refers to, you could probably also have enough privilege to be trusted with dirty/accessed bit.
Is this the sort of "within the capability model" you are referring to?