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@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 > ------------------------------------------------------------------------------ _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
