Hi Denis,
I am working on my thesis to implement a real-time capable checkpoint/restore mechanism in Genode/L4-Fiasco.OC on the Chair of Operating Systems, TUM Department of Informatics. A checkpoint component A has to transparently (more or less) store the internal state of another component B and restore it on another machine also running Genode.
let me refer to a recent discussion (back in March) that was closely related to the topic:
https://sourceforge.net/p/genode/mailman/genode-main/thread/CAPyx70Cy_v3WBcq...
to motivate your work, I would recommend you to state a tangible goal, i.e., an concrete example scenario that you want to realize. My sentiment is that many supposed use cases of a general checkpointing mechanism can be addressed differently and simpler on Genode. Please take the line of thinking that I presented as the second approach in the discussion above into consideration.
That said, I still find it worthwhile to experiment with the design and implementation of such a mechanism. Don't let me discourage you. ;-)
By searching the genode-main mailing list I found an idea for emulating the dirty-bit mechanism. In the message [1], the author suggests the use of managed dataspaces and a custom RAM service. The RAM server detaches a dataspace which a client is using, re-attaches and marks the dataspace when the client wants to read it or write to it. Thus, the server of the RAM service notices whenever a client uses a specific dataspace.
[1] https://sourceforge.net/p/genode/mailman/message/34787057/
The problem of this approach is the granularity of the dataspaces. I want to be notified when a virtual memory page is changed and store only this page. But using one RM session per 4 KiB dataspace (typical page size) is not efficient, because an RM session uses 64 KiB for itself.
This has changed in Genode 16.05. Now, one RM session can be used to create many managed dataspaces. Thereby, managed dataspaces have become much cheaper. The former functionality of the' Rm_session' has moved to 'Region_map'. Each PD is readily equipped with 3 region maps. The new 'Rm_session' interface allows the client to create further region caps. See the section in the release notes [1]. Please also consider to follow the changes I made in the new revision of the book [2] for version 16.05.
[1] http://genode.org/documentation/release-notes/16.05#Consolidation_of_core_s_... [2] https://github.com/nfeske/genode-manual/commit/7c165e92697932d2433e00316e5c9...
- Do I understand this approach correctly?
- Is there another way to be notified when a virtual memory page is
accessed?
Not via the Genode API. If you tie your work to a specific kernel, there may be additional kernel-specific mechanisms you could use. E.g., virtualization components like L4Linux (Fiasco.OC) , Seoul (NOVA), or VirtualBox (NOVA) invoke the kernel interface directly to manage a guest OS.
- If not, is it possible to extend the core with this mechanism. If yes,
which modules are involved?
I cannot give you a single true answer. There may be various designs possible, ranging from no modifications of core at all (e.g., via the approach followed by the Noux runtime or the RAM-server mentioned in the discussion you mentioned), over the use of a kernel-specific virtualization feature (monitoring the to-be-checkpointed component at a very low level like a virtual machine), to the extension of core's PD-session interface with a serialization/de-serialization feature. I am sure there are even plenty of more options.
Cheers Norman