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
