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@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
