Restoring child with checkpointed state
Stefan Kalkowski
stefan.kalkowski at ...1...
Thu Nov 2 14:03:50 CET 2017
Hi David
On 11/02/2017 10:35 AM, David Werner wrote:
> Hi,
>
> let me rephrase my question. Is "Thread::myself()->native_thread().kcap"
> returning the kcap of another capability than
> "Thread::myself->cap().data()->kcap()" ? As far as i understand yes. The
> former returns the kcap of the gate capability while the latter returns
> the capability of the thread object capability.
>
> If that is true, is there a possibility to access the gate capability
> from withtin the "Signal_source_rpc_object"
> [/repos/base-foc/src/include/signal_source/rpc_object.h] ?
>
sorry for my late response!
In fact, Thread::myself->cap() delivers the capability to the thread
object representation in core, not to mix up with the kernel-capability
that refers the actual thread! Therefore, I advised to send this
capability to core, and retrieve the "real" thread's capability out of
the Cpu session's object that belongs to the thread. You can use the
core's entrypoint, which is the same for Signal, Irq, Cpu, etc. to
retrieve the right Cpu_thread_component from the capability delivered by
the signal source client. Similar to this snippet:
entrypoint.apply(delivered_thread_cap, [&] (Cpu_thread_component *t) {
if (t) ... // attach t->platform_thread().thread().local
};
You can store the entrypoint within the Genode::Signal_source_rpc_object
by extending its constructor. Cpu_thread_component contains the
Platform_thread object of the thread including its "real" kernel capability.
A shortcut might be to propagate the gate capability to core instead,
simply by using native_thread(), which you already mentioned. In that
case, you can simply attach the received capability to the irq object.
But this is just a proof-of-concept implementation and inherently
insecure, as it opens up the possibility to attach signal sources to
arbitrary threads including threads of other protection domains.
Regards
Stefan
>
> Kind Regards,
>
> David
>
>
> Am 24.10.2017 um 02:11 schrieb David Werner:
>> Hi Stefan,
>>
>> i modified the request semaphore call and changed the constructor of
>> the Signal_source_client as follows:
>>
>>
>> [/repos/base-foc/src/lib/base/signal_source_client.cc] :
>>
>> Signal_source_client::Signal_source_client(Capability<Signal_source> cap)
>> :
>> Rpc_client<Foc_signal_source>(static_cap_cast<Foc_signal_source>(cap))
>> {
>> /* request mapping of semaphore capability selector */
>> _sem = call<Rpc_request_semaphore>(Thread::myself()->cap());
>> }
>>
>>
>>
>> [/repos/base-foc/src/include/signal_source/rpc_object.h] :
>>
>> Native_capability _request_semaphore(Thread_capability tcap) {
>>
>> Fiasco::l4_irq_detach(_blocking_semaphore.data()->kcap());
>>
>> Fiasco::l4_msgtag_t tag =
>> Fiasco::l4_irq_attach(_blocking_semaphore.data()->kcap(), 0,
>> tcap.data()->cap());
>> if (l4_error(tag))
>> Genode::raw("l4_irq_attach failed with ", l4_error(tag));
>>
>> return _blocking_semaphore;
>>
>> }
>>
>>
>> Unfortunately i run into problems if a component uses a timer. As soon
>> as timer.sleep is called the component waits forever.
>>
>> After taking a look at some code (especially Platform_thread) I think
>> the problem might be that i now use the kcap of the thread capability
>> for the l4_irq_attach call instead of the kcap of the corresponding
>> gate capability.
>>
>> Is that right or might there be another reason for my timer problem?
>>
>>
>> Kind Regards,
>>
>> David
>>
>>
>> Am 24.07.2017 um 14:18 schrieb Stefan Kalkowski:
>>> On 07/05/2017 02:00 PM, David Werner wrote:
>>>> Hi,
>>>>
>>>> it seems to work if i use <capability>.data()->kcap(). Is that correct?
>>> Yes.
>>>
>>> Regards
>>> Stefan
>>>
>>>> Kind Regards,
>>>> David
>>>>
>>>> Am 05.07.2017 um 13:46 schrieb David Werner:
>>>>> Hi Stefan,
>>>>>
>>>>> Am 29.06.2017 um 18:18 schrieb Stefan Kalkowski:
>>>>>> What I meant with:
>>>>>>
>>>>>> "... the signal handler thread transfers its identity to core via
>>>>>> request_semaphore..."
>>>>>>
>>>>>> was that you add an additional argument to the request_semaphore
>>>>>> call,
>>>>>> which is the CPU session's thread capability of the calling
>>>>>> thread, like
>>>>>> this:
>>>>>>
>>>>>> Thread::myself()->cap()
>>>>>>
>>>>>> Core can therewith retrieve the "real" thread capability, in terms of
>>>>>> the kernel's thread capability, and attach that to the IRQ object.
>>>>>> I hope I could get my ideas across to you.
>>>>>>
>>>>>> Best regards
>>>>>> Stefan
>>>>>>
>>>>> Thank you! I modified the request semaphore call according to your
>>>>> suggestion.
>>>>>
>>>>> My only problem is that i don't get how to use the transfered thread
>>>>> capability to retrieve the kernel's thread capability.
>>>>> More precisely, i'm not able to figure out how to determine the
>>>>> correct kcap which i have to use in the l4_irq_attach call (which is
>>>>> now on core's side).
>>>>>
>>>>> Could you give me some more advise on that?
>>>>>
>>>>> Kind Regards,
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> genode-main mailing list
>>>>> genode-main at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> genode-main mailing list
>>>> genode-main at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
--
Stefan Kalkowski
Genode Labs
https://github.com/skalk · http://genode.org/
More information about the users
mailing list