As Kevin said - yes.
One good place to research and look at this is the MIPS processor.
The MIPS hardware is minimum the interesting parts are done in software.

The exception handler works with a richer table of qualities that it manages.
The transition from user space to privileged space in the exception handler

sets the stage for all that might be needed.

I/O is difficult, a generation of Intel hardware had MTTR registers and address spaces

for I/O coherency. Today PAT (page attribute table) is used.
https://en.wikipedia.org/wiki/Page_attribute_table

Kernel and user space atomic operations are always in the critical path

and are not a given.
One last detail... I/O devices can modify memory in ways the CPU set of

multiple cores cannot seen in a coherent way unless the cache control bits are

correctly set. Physical, I/O and virtual mapped memory can have mismatched

control bits.

VM is difficult... it helped me to start with the MIPS model and look at what

can be crafted on top of a minimum but sufficient foundation.
Linux has support for multiple processors yet the user space sees a

common model.

On Thu, Aug 13, 2015 at 7:34 PM, Raymond Jennings <shentino@gmail.com> wrote:

So basically you use denied permissions to trap the access, and then emulate the access bits yourself?

On Thu, Aug 13, 2015 at 7:19 PM, Kevin Elphinstone <Kevin.Elphinstone@nicta.com.au> wrote:

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 “2^nd 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?

The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel

T o m M i t c h e l l