Checkpointing dataspaces in core

[Denis Huber]

Dear Genode Community,

perhaps my questions were too specific. Instead of answering them, I 
want to summarize them into one general question:

What is the general approach to read the address space content of a 
component within a custom service located in core?

(For identifying a component I can use its label.)


Thanks in advance
Denis

On 29.07.2016 12:15, Denis Huber wrote:
> Dear Genode community,
>
> I want to implement a new service (class Cr_session) residing in core
> which provides an Rpc method to checkpoint the state of a specific
> component (given its label string). I am using Genode 16.05 and the foc
> kernel (pbxa9 build). The first step is to store the content of the
> address space of the compoent. My approach is the following:
>
> 1) First a test component is created which shall be checkpointed. The
> component counts an integer every second.
>
> In base/src/test/cr_service/counter/main.cc (newly created file):
> !void Component::construct(Genode::Env &env)
> !{
> !    unsigned int n = 0;
> !    Timer::Connection timer(env);
> !
> !    while(1)
> !    {
> !        Genode::log(n);
> !        n++;
> !        timer.msleep(1000);
> !    }
> !}
>
> 2) To realize the CR service in core, I want to find the specific PD
> session of the test component. Therefore a separate Sliced_heap
> exclusively for Pd_session_component objects is created in core's main
> function.
>
> In base/src/core/main.cc:
> !static Sliced_heap pd_sliced_heap(env()->ram_session(),
> env()->rm_session());
> ![...]
> !static Pd_root pd_root(e, e, pager_ep, &pd_sliced_heap);
>
> 2) The CR service is registered and the special Sliced_heap is passed to
> the Root_component<Cr_session_component> object.
>
> In base/src/core/main.cc:
> !static Cr_root cr_root(e, &sliced_heap, &pd_sliced_heap);
> ![...]
> !static Local_service ls[] = {
> !    Local_service(Cr_session::service_name(), &cr_root),
> ![...]
> !}
>
> 3) In the implementation of the checkpoint method the Sliced_heap
> (stored in _alloced_pds) is searched for a Pd_session_component with a
> specific label string. The class implementing the Cr service
> (Genode::Cr_session_component : Rpc_object<Cr_session>) is a friend
> class in Sliced_heap and is allowed to access the _blocks member
> variable containing the Pd_session_component objects.
>
> In base/src/core/include/cr_session_component.h (newly created file):
> !bool checkpoint(String<64> label)
> !{
> !    Pd_session_component *pd = nullptr;
> !    bool found = false;
> !    Sliced_heap::Block *b = _alloced_pds->_blocks.first();
> !    for(; (b != 0) && !found; b = b->next())
> !    {
> !        pd = reinterpret_cast<Pd_session_component*>(b + 1);
> !        if(label == pd->_label.string) found = true;
> !    }
>
> 4) The Pd_session_component object is known and now it shall be used to
> access the test component's address space content. To retrieve the
> content I want to attach the Dataspace of the component's Region_map to
> core's Region_map.
>
> In base/src/core/include/cr_session_component.h (newly created file):
> !    Capability<Region_map> rm_cap = pd->address_space();
> !    Region_map_client rm_client(rm_cap);
> !    void* addr = core_env()->rm_session()->attach(rm_client.dataspace());
> !    return true;
> !}
>
> 5) After invoking rm_client.dataspace() the Rpc method never returns and
> the test scenario times out.
>
> What am I doing wrong? I compared the source code of other core services
> with the CR service and found no usage of classes derived from
> Rpc_client belonging to other core services. Is it not possible to use
> Rpc methods in core?
>
> I tested another solution where I only use Rpc_objects directly. I used
> pd_session_component::address_space_region_map() to access the
> address_space directly, where I think to find the memory content of the
> test component (Please correct me, if I am wrong).
> The following listing replaces the listing in step 4.
>
> In base/src/core/include/cr_session_component.h (newly created file):
> !    Dataspace_capability ds_cap =
> pd->address_space_region_map().dataspace();
> !    char* addr = core_env()->rm_session()->attach(ds_cap);
> !    log("Attaching dataspace: Returned pointer: ", addr);
> !
> !    Dataspace_component *ds_comp =
> pd->address_space_region_map().dataspace_component();
> !    log("Reading dataspace component");
> !    log("phys_addr = ", ds_comp->phys_addr(), " size = ",
> ds_comp->size(), " writable = ", ds_comp->writable() ? "true" : "false");
>
> The output of the log function was the following:
> Attaching dataspace: Returned pointer: 0x00000000
> Reading dataspace component
> phys_addr = 0 size = 3221221376 writable = false
>
> Now I got a null pointer and cannot read the content of the Region_map
> of the test component.
>
>
> Can someone help me to answer the following questions:
> * Can I use Capability invokation in core, where the Rpc_object belongs
> to another core service? If yes, how? Perhaps, my problem is the correct
> retrieval of the Pd_session_component, thus I can invalid Capabilities.
> * Why do I get an invalid pointer from the attach method of core's
> Region_map? Is it not allowed to attach dataspaces in core? Are they
> already attached in core, and I only need the pointer to the memory? Is
> the Dataspace_capability invalid?
>
>
> Kind regards
> Denis
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>