Hello,
Another solution would be a second component that polls for the memory state of the supervised component. This might be efficient if your interest is restricted to a small range of the target address space.
I think that Martin's suggestion of managed dataspaces points in the right direction. But in contrast to Martin, I don't think that there is the need for an instruction emulator. How about the following approach?
* In line with Martin's suggestions, instead of obtaining RAM dataspaces from core, there is a new RAM service (let's call it VRAM for now) that hands out managed dataspaces instead of real RAM dataspaces. Managed dataspaces represent a mechanism for implementing virtual memory in user space. You can find an example at [1]. Note however that this mechanism requires a kernel that supports the remote manipulation of address spaces. This is the case for all of Genode's base platforms except Linux.
[1] repos/base/src/test/rm_fault/main.cc
* Initially, when handing out a dataspace, the VRAM server attaches a real RAM dataspace within the managed dataspace. So the client can access it as usual. It would not notice any difference from a regular RAM dataspace.
* From time to time, the VRAM server, detaches the RAM dataspace from the managed dataspace.
* The next time the client tries to access the dataspace, it would stop executing. Under the hood, a page fault occurs, which is reflected by the kernel (and Genode's core) to the VRAM server as a signal (RM-fault signal). The VRAM server wakes up upon the reception of the signal and thereby knows that the dataspace was accessed. It can even determine the fault address via the Rm_session::state operation. It can respond to the signal be re-attaching the RAM dataspace to the managed dataspace. This operation will implicitly resume the execution of the client.
In principle, this approach implements a mechanism similar to the dirty-bits in the MMU page tables. The VRAM server becomes able to track the accesses to the dataspace and may copy its content. From the client's perspective, the monitoring is completely transparent. If you want to track the usage of the managed dataspace at a fine granularity, the VRAM server might attach the RAM dataspace as several pieces to the managed dataspace (by using the offset, size, and local_addr arguments to the Rm_session::attach operation).
The only open question left is how to pick a suitable interval of detaching the RAM dataspace from the managed dataspace?
Cheers Norman