Re: Page faults in managed dataspaces

[Denis Huber]

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():::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=0x
> [init -> ckpt]   attached sub_ds0 at address 0x
> [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():::Could
> not resolve pf=6000 ip=10034bc
> [init -> ckpt] Handling page fault: 

Re: Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules

[Paul Dufresne]

Sorry, my mistake.
that's Console::enable in console.hpp which seems to have nothing with
interruptions.

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules

[Paul Dufresne]

Well, now that you mentions things that does not seems to make sense
in Console_VGA
constructor, it ends with: enable() which I would presume is enable
interruptions (did not check).

But Idt::build(); (Interrupt Descriptor Table) will be called only
after Hip::build too in init.

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules

[Christian Helmuth]

Hello,

On Fri, Sep 23, 2016 at 07:21:33PM -0400, Paul Dufresne wrote:
> But then again, the constructors is called before Hip::build (mbi); in
> nova init, which reads command line.
> So novga cannot have effect yet.

If this would be true the following code makes no sense to me.

  src/console_vga.cpp:29

  if (Cmdline::novga)
  return;

You could still just put 'return;' before line 29 to prevent VGA
initialization. On the other hand, this does not avoid running into
the same issue later during bootstrap. I'm curious what you'll find
out about the 'new (quota)' suspicion.

Regards
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main