On Tue, Apr 25, 2023 at 12:02 PM Sergey Bugaev <buga...@gmail.com> wrote: > subcode is the address of the fault, and 128 just so happens to be > 0x80, and %fs:0x80 is of course tcb->reply_port. So it looks like > fs_base was not restored to its proper value when context-switching to > the thread, and gets instead set to 0, and so accessing the reply port > to make an RPC faults. > > But how come all the previous RPCs worked? Well, it looks like fs_base > is restored/preserved correctly when just doing synchronous kernel RPC > calls, but not when the thread is continued after reading via > io_done_thread_continue/thread_invoke/call_continuation.
This is of course a wrong way to do this, but just for the sake of testing: diff --git a/kern/sched_prim.c b/kern/sched_prim.c index dd0f492b..820de799 100644 --- a/kern/sched_prim.c +++ b/kern/sched_prim.c @@ -55,6 +55,7 @@ #include <vm/pmap.h> #include <vm/vm_kern.h> #include <vm/vm_map.h> +#include <i386/msr.h> #if MACH_FIXPRI #include <mach/policy.h> @@ -733,6 +734,10 @@ boolean_t thread_invoke( counter(c_thread_invoke_hits++); (void) spl0(); +#ifdef __x86_64__ + wrmsr(MSR_REG_FSBASE, new_thread->pcb->iss.fsbase); + wrmsr(MSR_REG_GSBASE, new_thread->pcb->iss.gsbase); +#endif call_continuation(new_thread->swap_func); /*NOTREACHED*/ return TRUE; /* help for the compiler */ And sure enough: start bc: bc 1.07.1 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 2 + 3 5 print "Hello from x86_64-gnu!" Hello from x86_64-gnu! Now's the time to admit I don't really know how to use bc :D Sergey