Genode 16.05 Fault handler
Denis Huber
huber.denis at ...435...
Tue Sep 6 11:29:15 CEST 2016
Hello Sebastian,
Thank you very much for your help :) The little fix is also working for me.
Kind regards,
Denis
On 05.09.2016 19:04, Sebastian Sumpf wrote:
> He Denis,
>
> On 09/03/2016 12:03 PM, Denis Huber wrote:
>> Hello Sebastian,
>>
>> I think, I have expressed myself incorrectly. I don't want to handle the
>> page faults with the same thread which also causes them. I want to find
>> out the usage of the new Signal_handler API: I want to create a simple
>> component which causes a page fault and which also registers a page
>> fault handler for its address space, which wil resolve the page faults
>> in a separate Entrypoint (= separate Thread).
>>
>> Practically, I have created a test scenario [1] with the old
>> Signal_receiver and Signal_context syntax, where a component registers a
>> page fault handler for its address space and then causes a page fault.
>>
>> [1]
>> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/7c1c6183a5132aa67d2604221d4eb6ee39106c64/src/test/fault_handler_old/main.cc
>>
>> Now, I want to change this scenario to use the new Signal_handler
>> syntax, where a component registers a Signal_handler and then causes a
>> page fault, which is handled by the Signal_handler.
>>
>> My understanding of a Signal_handler is, that the Entrypoint, which is
>> passed at the creation of a Signal_handler, catches a page fault signal
>> from core and calls the function passed to the Signal_handler. Because
>> an Entrypoint is basically a thread, it will do the same as
>> Local_fault_handler class in [1] (Is it correct?).
>>
>> Based on that thoughts I created this component [2].
>>
>> [2]
>> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/81f6a705b5b57bc992c47566747a8273fb056c33/src/test/fault_handler/main.cc
>>
>> I handle the "hen and egg" problem with a separate Entrypoint which is
>> actually another thread (other then the thread which causes the page
>> fault). But my solution does not work. Where do I have a
>> misunderstanding of the Signal_handler/Entrypoint concept?
>>
>> Basically, I want to know how to handle page faults using a
>> Signal_handler object. In my project I will use a parent component,
>> which will create several Region_maps and provide one Signal_handler for
>> all those Region_maps. One Region_map is given to the child as a
>> dataspace, when it allocates ram from its ram_session. The Region_map is
>> initially empty. When the child accesses an address in that Region_map,
>> the caused page fault will be caught by the Signal_handler and a
>> dataspace, backed with physical memory, attached.
>
> You seem to be doing it all right. I have updated the recent fault
> handler example to use a second entrypoint
> (https://github.com/ssumpf/genode/commit/ff23c7227944324b55fc281f26b8e5bfc12e14fa).
> Doing this, I experienced the same problems as yourself. Namely, that
> the page-fault signal is not delivered. This is caused by the fact of
> the signal proxy thread of the entrypoint (that delivers the signal) not
> being started. I fixed this and it works for now. It might just be a
> bug, but I will discuss this issue tomorrow.
>
> Regards,
>
> Sebastian
>
>> Thank you for your help in advance ^^
>>
>>
>> Kind regards,
>> Denis
>>
>> On 31.08.2016 18:23, Sebastian Sumpf wrote:
>>> Hi Denis,
>>>
>>> On 08/31/2016 02:24 PM, Denis Huber wrote:
>>>> Hello Sebastian,
>>>>
>>>> thank you for the working solution :)
>>>>
>>>> Now the page faults of threads other than the main-thread can be
>>>> handled. What about the main-thread? How can I change the example to be
>>>> able to handle page faults from the main-thread?
>>>>
>>>> Do I have to create an extra thread which is dedicated to handle page
>>>> faults of the other threads like the old Signal_receiver/Signal_context
>>>> approach [1]? I thought the new design of the Entrypoint provides this
>>>> feature (Entrypoint handles page faults in its thread). Or is my
>>>> understanding wrong?
>>>
>>> as I said yesterday, a thread (what an EP essentially is) cannot handle
>>> its own page fault. It is a hen and egg problem. Microkernels just save
>>> the thread state and call a pager thread in order to resolve the page
>>> fault. Note, that this thread does not have to be within the same
>>> program (or protection domain). What I don't understand, why would you
>>> want a self paging program? The memory has to be provided and paged from
>>> the outside anyway (in Genode that would be the parent or core)?
>>>
>>> Cheers,
>>>
>>> Sebastian
>>>
>>>>
>>>> [1]
>>>> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/7c1c6183a5132aa67d2604221d4eb6ee39106c64/src/test/fault_handler_old/main.cc
>>>>
>>>>
>>>> Kind regards,
>>>> Denis
>>>>
>>>> On 30.08.2016 18:36, Sebastian Sumpf wrote:
>>>>> Hi Denis,
>>>>>
>>>>> On 08/30/2016 04:21 PM, Denis Huber wrote:
>>>>>> Hello Sebastian,
>>>>>>
>>>>>> I created a new thread which causes the page fault, and also assigned an
>>>>>> extra Entrypoint for the Signal_handler [1], but still no success.
>>>>>> Perhaps I am using the Signal_handler in a wrong way.
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/c58b4144bff720f837112c590ebd2148e9c3f199/src/test/fault_handler/main.cc
>>>>>>
>>>>>
>>>>> You are mixing some things up here, I pushed a working version of your
>>>>> code (tested on Fisco.OC in Qemu) to GitHub:
>>>>>
>>>>> https://github.com/ssumpf/genode/commit/0075a0026faa8079f03dfb4d43ec281ef51f1083
>>>>>
>>>>> I hope this clarifies things a little. The relevant output should look
>>>>> like this:
>>>>>
>>>>>> [init -> pf-signal_handler] --- pf-signal_handler started ---
>>>>>> no RM attachment (WRITE pf_addr=1000 pf_ip=10001d9 from 2d2000)
>>>>>> Warning: could not resolve pf=0x1000 ip=0x10001d9
>>>>>> [init -> pf-signal_handler] Region map state is WRITE_FAULT pf_addr=0x1000
>>>>>> [init -> pf-signal_handler] Allocating dataspace and attaching it to the region map
>>>>>> [init -> pf-signal_handler] --- pf-signal_handler ended ---
>>>>>
>>>>> Sebastian
>>>>>
>>>>> P.S. As I see it, you needed the 'join' because the thread was created
>>>>> on the stack again ;) One has to use the heap or bss/data.
>>>>>
>>>>>
>>>>>> Kinds regards,
>>>>>> Denis
>>>>>>
>>>>>> On 30.08.2016 15:45, Sebastian Sumpf wrote:
>>>>>>> Hello again,
>>>>>>>
>>>>>>> I missed that part
>>>>>>>
>>>>>>>> *((unsigned int*)0x1000) = 1;
>>>>>>>
>>>>>>> in my last reply. You cannot cause a page fault in your entry point and
>>>>>>> also handle it in the entry point thread, because the entry point is not
>>>>>>> able to receive signals when it is in page fault. It is a hen and egg
>>>>>>> problem.
>>>>>>>
>>>>>>> If you cause the fault from another Genode thread, it should work as
>>>>>>> expected.
>>>>>>>
>>>>>>> Sebastian
>>>>>>>
>>>>>>>
>>>>>>> On 08/30/2016 03:07 PM, Denis Huber wrote:
>>>>>>>> Hello Sebastian,
>>>>>>>>
>>>>>>>> I moved sigh to the member attributes [1], but without success. I also
>>>>>>>> tried to use a heap to store the Signal_handler, also without success.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/93eaec436ce9b6d3b3a6663558bff9af925ae70f/src/test/fault_handler/main.cc#L19
>>>>>>>>
>>>>>>>> I am using run script [2], if it helps.
>>>>>>>>
>>>>>>>> [2]
>>>>>>>> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/93eaec436ce9b6d3b3a6663558bff9af925ae70f/run/fault_handler.run
>>>>>>>>
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Denis
>>>>>>>>
>>>>>>>> On 30.08.2016 14:36, Sebastian Sumpf wrote:
>>>>>>>>> Hi Denis,
>>>>>>>>>
>>>>>>>>>> Signal_handler<Main> sigh = {env.ep(), *this, &Main::_handle_fault};
>>>>>>>>>
>>>>>>>>> The line above, creates the Signal_handler on the stack and destructs
>>>>>>>>> this handler as soon as the 'Main' constructor is finished.
>>>>>>>>>
>>>>>>>>> Therefore, 'sigh' should be a member of the 'Main' class.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Sebastian
>>>>>>>>>
>>>>>>>>> On 08/30/2016 02:10 PM, Denis Huber wrote:
>>>>>>>>>> Dear Genode community,
>>>>>>>>>>
>>>>>>>>>> in Genode 16.05 the old usage of Signal_receivers and Signal_contexts is
>>>>>>>>>> considered deprecated. Instead Signal_handler and Signal_transmitter
>>>>>>>>>> shall be used.
>>>>>>>>>>
>>>>>>>>>> I am trying to use a Signal_handler as a fault handler for env's address
>>>>>>>>>> space. I wrote a short test to illustrate the problem [1].
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/c9a5a1f999a2ce1c6ffd5c316eee127c93d87308/src/test/fault_handler/main.cc
>>>>>>>>>>
>>>>>>>>>> The output of [1] is as follows:
>>>>>>>>>> "
>>>>>>>>>> [init -> pf-signal_handler] --- pf-signal_handler started ---
>>>>>>>>>> no RM attachment (WRITE pf_addr=1000 pf_ip=100061c from 2ae000)
>>>>>>>>>> Genode::Pager_entrypoint::entry()::<lambda(Genode::Pager_object*)>:
>>>>>>>>>> Could not resolve pf=1000 ip=100061c
>>>>>>>>>> "
>>>>>>>>>>
>>>>>>>>>> The signal handler was registered correctly, because the line
>>>>>>>>>> "
>>>>>>>>>> Genode::Core_pd_session_component::submit(Genode::Capability<Genode::Signal_context>,
>>>>>>>>>> unsigned int)::<lambda(Genode::Signal_context_component*)>: invalid
>>>>>>>>>> signal-context capability
>>>>>>>>>> "
>>>>>>>>>> is missing. However, the method _handle_fault() is never entered. What
>>>>>>>>>> am I doing wrong?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Denis
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> _______________________________________________
>>>>>>>>>> genode-main mailing list
>>>>>>>>>> genode-main at lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> _______________________________________________
>>>>>>>>> genode-main mailing list
>>>>>>>>> genode-main at lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> _______________________________________________
>>>>>>>> genode-main mailing list
>>>>>>>> genode-main at lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> genode-main mailing list
>>>>>>> genode-main at lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> genode-main mailing list
>>>>>> genode-main at lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> genode-main mailing list
>>>>> genode-main at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> genode-main mailing list
>>>> genode-main at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> genode-main mailing list
>>> genode-main at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> genode-main mailing list
>> genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
More information about the users
mailing list