Hello, Continuing my bad habit of following up to my own messages...
On Tuesday, 19 April 2022 01:20:30 CEST Paul Boddie wrote: > > Doing some "old school" tracing in various routines like transfer_msg_items > by detecting the appropriate fault conditions, enabling tracing, and then > producing output on the console doesn't seem to yield any indications of > the messages being processed, but perhaps I misunderstand the flow of > control from Thread::handle_page_fault_pager within the kernel when the IPC > is initiated. > > Reviewing the old thread on this broader topic, I found this advice: > > http://os.inf.tu-dresden.de/pipermail/l4-hackers/2014/015441.html > > This does yield page fault trace log entries of the following form: > > pf: 00bc pfa=0000000001000ae3 ip=0000000001000ae3 (rp) > spc=0xffffffff13dc5ad8 err=15 > > Here, I presume that the error is R_aborted (src/abi/l4_error.cpp), meaning > that the page fault was not handled. I see that formatter_pf (in src/kern/tb_entry_output.cc) is responsible for this form of output. Similarly, formatter_ipc and formatter_ipc_res seem to be responsible for the IPC-related log entries. The log entries appear to be populated when Thread::handle_page_fault (in src/ kern/thread-pagefault.cpp) calls page_fault_log (in src/kern/thread-log.cpp), which populates a Tb_entry_pf instance with the given error details. So, it seems like the reported error is that causing the page fault, not any kind of eventual outcome. > Looking at advice about IPC tracing... > > http://os.inf.tu-dresden.de/pipermail/l4-hackers/2014/015475.html > > ...I can also get log entries that I think might indicate some element of > success in terms of the messages being sent, with this being the fault > message: > > 00be answ [fffffffffffe0002] L=8000fcf3 err=0 (OK) (1000ae5,1000ae3) > ipc: 00be wait->[C:INV] DID=be L=0 TO=INF > > And elsewhere: > > 00be answ [00000040] L=0 err=0 (OK) (1000038,400595) > ipc: 00be send rcap->[C:INV] DID=bc L=0 [0000000000000040] > (0000000001000038,0000000000400595) TO=INF > > Here, I am attempting to resolve the page fault caused by execution at > 0x1000ae3 by sending a flexpage providing memory in one task at 0x400000 to > the recipient at 0x1000000. > > None of this really explains why the page fault handler keeps getting called > with the same details, sending the same message, and so on. I still can't explain this. Doing some more invasive debugging in Task::sys_map (in src/kern/task.cpp) indicates that an explicit l4_task_map call will cause fpage_map (in src/kern/map_util.cpp) and subsequently mem_map (in src/kern/map_util-mem.cpp) and then map (in src/kern/map_util.cpp) to be called, attempting to map 0x400000 (with size 0x400000) in the original task at 0x1000000 in the recipient. This is reportedly successful. With page fault handling, the fpage_map, mem_map and map functions are called similarly, with the same supposedly successful outcome. But the page fault continues to occur with the same details, as if the mapping did not actually happen. I did wonder if it might be due to the original task not really having the pages it is trying to "export" actually mapped in itself (this being a potential pitfall when implementing dataspaces, in my experience), but this is not the case. I suppose I must be overlooking something else... Paul _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
