Process migration and persistence

Norman Feske norman.feske at ...1...
Thu Mar 17 18:07:09 CET 2016

Hi Daniel,

great to see you back in Genode land! :-)

> I'd like to be able to freeze a process (PD or even a vmm), make it
> persistent, and unfreeze at some later point in time.  Does anyone have
> suggestions/pointers on how to do this?

This does not work out of the box but I see two principal approaches:

1) You can run the to-be-frozen program as a child of a custom runtime
   environment that intercepts the program's PD, CPU, RM, and RAM
   sessions. So the environment knows everything that goes on within
   the program. This is what the Noux runtime is doing. Thanks to
   this approach, we are able to implement fork on top of Genode. This
   is actually very similar to what you want to achieve. Instead of
   replicating the forking program, however, you would serialize/
   unserialize this information. That said, there are some constraints
   worth noting. Most importantly, the new process "forgets" all its
   capabilities. So it must re-obtain them in order to work as
   expected. In Noux processes, this is possible because we hide
   Genode capabilities behind the POSIX API. So only the libc deals
   with capabilities and can actively re-establish them after the

   Another example to look at is the GDB monitor. Similar to Noux,
   it intercepts the said core services. But it uses them to inspect
   and control the to-be-debugged program.

2) Our general agenda is to create components as mere state
   machines that are fed with state (e.g., using ROM sessions)
   and propagate their results (e.g., using Report sessions). Since
   such components don't contain unrecoverable internal state,
   we can just kill and restart them. When presented with the
   same imported state (aka ROM sessions) after the restart, they
   end up in the same internal state as before. A practical
   example of this approach is the way, the window decorator
   interacts with the window manager in the Turmvilla scenario.
   Here, we can dynamically replace one decorator component by
   another implementation while retaining all of the window layout.

   This approach just defines the problem away, which I find very
   nice. :-)

For complex monolithic applications with comprehensive internal state,
there is the further option to run it with a VM (i.e., VirtualBox).
Although we haven't tried it with our port, VirtualBox comes with the
ability to suspend a VM to a file. I think this feature could be enabled
in our version of VirtualBox without too much trouble.

Can you share more details about your use case?


Dr.-Ing. Norman Feske
Genode Labs ·

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

More information about the users mailing list