Hey,
This MRC is a privileged instruction and cannot be called in user-level. If for whatever reason you need to know DFAR (why?), you need to do the mrc in the kernel and have an interface to retrieve it from there. Taking any security considerations aside, add another function to L4::Thread (Thread_object in the kernel) to get the value, it's an easy option.
I did this now, we already had a custom function that reads all the general purpose registers, and IP and SP (by calling Thread::user_ip() and Thread::user_sp()) so there I inserted my assembler call. Now the call doesn't freeze the system anymore and it returns a value. But the strange thing is that when I have 3 threads in a process and only 1 is faulting and I call this function for all of them, they all return the same value from their DFAR (0xe07c). When I instead read the DFSR (c5 instead of c6), they all return 0x7. But I'm thinking that when only one of the threads is faulting, their DFSRs or DFARs should return different values. What am I missing? The IP and SP registers appear to be read correctly and with different values.
(why?)
I have a userspace application that has registered itself as fault handler for its child. Now, when a page fault arrives, I want to identify the faulting thread by comparing the page fault address from the pf-report with the DFAR registers of each of the threads. I'm using Genode on top of Fiasco.OC, and Genode's pagefault report doesn't include a direct way to identify/access the faulting thread.
Thanks for your help!
Best regards, Josef