Writing to two different dataspaces at the same time
norman.feske at ...1...
Fri Jan 22 12:53:38 CET 2016
> 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 . 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.
* 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?
Dr.-Ing. Norman Feske
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the users