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.
Thank you for your help in advance ^^
Kind regards,
Denis
Post by Sebastian SumpfHi Denis,
Post by Denis HuberHello 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
Post by Denis Huber[1]
https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/7c1c6183a5132aa67d2604221d4eb6ee39106c64/src/test/fault_handler_old/main.cc
Kind regards,
Denis
Post by Sebastian SumpfHi Denis,
Post by Denis HuberHello 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
https://github.com/ssumpf/genode/commit/0075a0026faa8079f03dfb4d43ec281ef51f1083
I hope this clarifies things a little. The relevant output should look
Post by Denis Huber[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.
Post by Denis HuberKinds regards,
Denis
Post by Sebastian SumpfHello 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
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
Post by Sebastian SumpfHi 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
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
"
[init -> pf-signal_handler] --- pf-signal_handler started ---
no RM attachment (WRITE pf_addr=1000 pf_ip=100061c from 2ae000)
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
https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------