Re: Writing to two different dataspaces at the same time

[Norman F. <nor...@ge...>]

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

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