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