Dear Genode Community, perhaps the wall of text is a bit discouraging to tackle the problem. Let me summaries the important facts of the scenario:
* Two components 'ckpt' and 'target' * ckpt shares a thread capability of target's main thread * ckpt shares a managed dataspace with target * this managed dataspace is initially empty target's behaviour: * target periodically reads and writes from/to the managed dataspace * target causes page faults (pf) which are handled by ckpt's pf handler thread * pf handler attaches a pre-allocated dataspace to the managed dataspace and resolves the pf ckpt's behaviour: * ckpt periodically detaches all attached dataspaces from the managed dataspace Outcome: After two successful cycles (pf->attach->detach -> pf->attach->detach) the target does not cause a pf, but reads and writes to the managed dataspace although it is (theoretically) empty. I used Genode 16.05 with a foc_pbxa9 build. Can somebody help me with my problem? I actually have no idea what could be the problem. Kind regards, Denis On 19.09.2016 15:01, Denis Huber wrote: > Dear Genode Community, > > I want to implement a mechanism to monitor the access of a component to > its address space. > > My idea is to implement a monitoring component which provides managed > dataspaces to a target component. Each managed dataspace has several > designated dataspaces (allocated, but not attached, and with a fixed > location in the managed dataspace). I want to use several dataspaces to > control the access range of the target component. > > Whenever the target component accesses an address in the managed > dataspace, a page fault is triggered, because the managed dataspace has > no dataspaces attached to it. The page fault is caught by a custom page > fault handler. The page fault handler attaches the designated dataspace > into the faulting managed dataspace and resolves the page fault. > > To test my concept I implemented a prototypical system with a monitoring > component (called "ckpt") [1] and a target component [2]. > > [1] > https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/b502ffd962a87a5f9f790808b13554d6568f6d0b/src/test/concept_session_rm/server/main.cc > [2] > https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/b502ffd962a87a5f9f790808b13554d6568f6d0b/src/test/concept_session_rm/client/main.cc > > The monitoring component provides a service [3] to receive a Thread > capability to pause the target component before detaching the dataspace > and resume after detaching and to provide a managed dataspace to the client. > > [3] > https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/tree/b502ffd962a87a5f9f790808b13554d6568f6d0b/include/resource_session > > The monitoring component runs a main loop which pauses the client's main > thread and detaches all attached dataspaces from the managed dataspace. > The target component also runs a main loop which prints (reads) a number > from the managed dataspace to the console and increments (writes) it in > the managed dataspaces. > > The run script is found here [4]. > > [4] > https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/b502ffd962a87a5f9f790808b13554d6568f6d0b/run/concept_session_rm.run > > The scenario works for the first 3 iterations of the monitoring > component: Every 4 seconds it detaches the dataspaces from the managed > dataspace and afterwards resolves the page faults by attaching the > dataspaces back. After the 3. iteration, the target component accesses > the theoretically empty managed dataspaces, but does not trigger a page > fault. In fact, it reads and writes to the designated dataspaces as if > it was attached. > > By running the run script I get the following output: > [init -> target] Initialization started > [init -> target] Requesting session to Resource service > [init -> ckpt] Initialization started > [init -> ckpt] Creating page fault handler thread > [init -> ckpt] Announcing Resource service > [init -> target] Sending main thread cap > [init -> target] Requesting dataspace cap > [init -> target] Attaching dataspace cap > [init -> target] Initialization ended > [init -> target] Starting main loop > Genode::Pager_entrypoint::entry()::<lambda(Genode::Pager_object*)>:Could > not resolve pf=6000 ip=10034bc > [init -> ckpt] Initialization ended > [init -> ckpt] Starting main loop > [init -> ckpt] Waiting for page faults > [init -> ckpt] Handling page fault: READ_FAULT pf_addr=0x00000000 > [init -> ckpt] attached sub_ds0 at address 0x00000000 > [init -> ckpt] Waiting for page faults > [init -> target] 0 > [init -> target] 1 > [init -> target] 2 > [init -> target] 3 > [init -> ckpt] Iteration #0 > [init -> ckpt] valid thread > [init -> ckpt] detaching sub_ds_cap0 > [init -> ckpt] sub_ds_cap1 already detached > Genode::Pager_entrypoint::entry()::<lambda(Genode::Pager_object*)>:Could > not resolve pf=6000 ip=10034bc > [init -> ckpt] Handling page fault: READ_FAULT pf_addr=0x00000000 > [init -> ckpt] attached sub_ds0 at address 0x00000000 > [init -> ckpt] Waiting for page faults > [init -> target] 4 > [init -> target] 5 > [init -> target] 6 > [init -> target] 7 > [init -> ckpt] Iteration #1 > [init -> ckpt] valid thread > [init -> ckpt] detaching sub_ds_cap0 > [init -> ckpt] sub_ds_cap1 already detached > [init -> target] 8 > [init -> target] 9 > [init -> target] 10 > [init -> target] 11 > [init -> ckpt] Iteration #2 > [init -> ckpt] valid thread > [init -> ckpt] sub_ds_cap0 already detached > [init -> ckpt] sub_ds_cap1 already detached > [init -> target] 12 > [init -> target] 13 > > As you can see: After "iteration #1" ended, no page fault was caused, > although the target component printed and incremented the integer stored > in the managed dataspace. > > Could it be, that the detach method was not executed correctly? > > > Kind regards > Denis > > ------------------------------------------------------------------------------ > _______________________________________________ > genode-main mailing list > genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > ------------------------------------------------------------------------------ _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main