Re: [Qemu-devel] Page protection and i386 cmpxchg8b

[Pierre d'Herbemont]

On 23 févr. 07, at 23:56, Ilya Shar wrote:

> Sure.  At first I was hitting unsupported mach
> syscalls, so I modified darwin-user/syscall.h
> according to
> /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/mach/syscall_sw.h
> :
>
> $ diff syscall.c syscall.c.orig
> 458,465d457
> <     case -33:
> <         DPRINTF("semaphore_signal_trap(0x%x)\n",
> arg1);
> <         ret = semaphore_signal_trap(arg1);
> <         break;
> <     case -34:
> <         DPRINTF("semaphore_signal_all_trap(0x%x)\n",
> arg1);
> <         ret = semaphore_signal_all_trap(arg1);
> <         break;
> 471,474d462
> <     case -37:
> <         DPRINTF("semaphore_wait_signal_trap(0x%x,
> 0x%x)\n", arg1, arg2);
> <         ret = semaphore_wait_signal_trap(arg1,arg2);
>
> <         break;

cvs diff -u would be easier to read for me. (or diff -u). You could  
send this patch to the qemu-devel, that would be cool.

> With this Sfari went past the unsupported call -33 and
> now stops in call -61 (syscall_thread_switch).  Can I
> just modify syscalls.c in a similar way to fix it?

Yes you can!

> But a really alarming thing happens before it gets
> there.  If my ethernet cable is not plugged in,
> cmpxchg8b write to a nonwritable page brings my system
> down.  I suppose it happens in somewhere in the
> drivers.

Ouch! I have noticed the same: qemu can trigger bugs really easily at  
the kernel level :( Could you explain how you know that cmpxchg8b is  
the key to our problem? Also qemu signal handlers might be overridden  
by some mach calls, that could explain the problem you are  
encountering. We need to work on this.

Pierre.