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/7c1c6...
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/81f6a...
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/ff23c7227944324b55fc281f26b8e5bfc12e...). 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/7c1c6...
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/c58b4...
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/0075a0026faa8079f03dfb4d43ec281ef51f...
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/93eae... >> >> I am using run script [2], if it helps. >> >> [2] >> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/93eae... >> >> >> 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/c9a5a... >>>> >>>> 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::CapabilityGenode::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@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/genode-main >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> genode-main mailing list >>> genode-main@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/genode-main >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> genode-main mailing list >> genode-main@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/genode-main >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > genode-main mailing list > genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main >
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main