Re: [Qemu-devel] Page protection and i386 cmpxchg8b
On 27 févr. 07, at 08:22, Ilya Shar wrote: Please see the diff file attached. I meant send a diff to the qemu-devel in a new mail with [Patch] in the subject so that it can be committed :-) However, at second thought, I think that it might need some re-work, see [1], and the arguments might need to be byte-swapped. Any suggestions how to fix this? As I said before, I think that the problem appears because: qemu signal handlers might be overridden by some mach calls, that could explain the problem you are encountering. We need to work on this. That's really not easy to fix, in two words. [1] I think it should consist in writing a custom implementation of semaphore_signal_trap, semaphore_signal_thread_trap, semaphore_wait_signal_trap, etc. that hook into signal.c. Tell me if you want more info on this. Pierre. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Page protection and i386 cmpxchg8b
--- Pierre d'Herbemont <[EMAIL PROTECTED]> wrote: > ... > 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. > Pierre, Please see the diff file attached. > ... > 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? Stepping in gdb I saw that cmpxchg8b attempts to write to a protected page. Besides, when the system crashes, here's what I see in the crash log in the Console app: ... Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x2111faf5 Thread 0 Crashed: 0 qemu-i386 0x0e02254b stq_le_p + 50 (cpu-all.h:344) 1 qemu-i386 0x0e0224d6 helper_cmpxchg8b + 192 (helper.c:1523) 2 <<>>0x0e1361b4 code_gen_buffer + 708980 3 qemu-i386 0x0e000db3 cpu_loop + 23 (main.c:498) 4 qemu-i386 0x0e001f75 main + 2814 (main.c:917) 5 qemu-i386 0x0e000a8e _start + 216 6 qemu-i386 0x0e0009b5 start + 41 ... Any suggestions how to fix this? Thanks for your help! Ilya > 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. > Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 darwin-user_syscall.c_diff Description: 2740739241-darwin-user_syscall.c_diff ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Page protection and i386 cmpxchg8b
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.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Page protection and i386 cmpxchg8b
--- Pierre d'Herbemont <[EMAIL PROTECTED]> wrote:
Hi Pierre,
Thanks for your reply - please see comments inserted
below:
> Hi Ilya!
>
> On 23 févr. 07, at 21:32, Ilya Shar wrote:
>
> > I'm running i386-darwin-usrer on i386 and some
> apps
> > (Safari browser) crash because cmpxchg8b attempts
> to
> > wrie to a qemu-allocated page which is readable
> but
> > write-protected. When I comment out mprotect in
> > exec.c
>
> Are you sure it does Safari does crash because of
> that call? I have
> the Apple Bug Reporter which complains about the
> fact that qemu gets
> a EXC_BAD_ACCESS, but then I get this error:
> qemu: Unsupported mach syscall: -61(0xffc3) (=
> semaphore_signal_trap)
> or
> qemu: Unsupported mach syscall: -33(0xffdf) (=
> syscall_thread_switch)
>
> To fix this we have to implement those syscalls.
>
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;
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?
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.
...
>
> I think the idea behind the mprotect is to make sure
> that any changes
> to this pages gets monitored, and that the tb can be
> invalidated if
> the code was modified (self modify-ing code).
That makes sense. Still I am not sure why cmpxchg8b
causes problems.
Thanks!
Ilya
>
> Pierre.
>
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Page protection and i386 cmpxchg8b
Hi Ilya! On 23 févr. 07, at 21:32, Ilya Shar wrote: I'm running i386-darwin-usrer on i386 and some apps (Safari browser) crash because cmpxchg8b attempts to wrie to a qemu-allocated page which is readable but write-protected. When I comment out mprotect in exec.c Are you sure it does Safari does crash because of that call? I have the Apple Bug Reporter which complains about the fact that qemu gets a EXC_BAD_ACCESS, but then I get this error: qemu: Unsupported mach syscall: -61(0xffc3) (= semaphore_signal_trap) or qemu: Unsupported mach syscall: -33(0xffdf) (= syscall_thread_switch) To fix this we have to implement those syscalls. //mprotect(g2h(page_addr), qemu_host_page_size, // (prot & PAGE_BITS) & ~PAGE_WRITE); I can proceed further. I would guess mprotect is there for a reason so it doesn't seem like a good solution, besides the runs get substantially slower without mprotect. Is there a solution to this problem or a way to better understand what is going on? I think the idea behind the mprotect is to make sure that any changes to this pages gets monitored, and that the tb can be invalidated if the code was modified (self modify-ing code). Pierre. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Page protection and i386 cmpxchg8b
Hi, I'm running i386-darwin-usrer on i386 and some apps (Safari browser) crash because cmpxchg8b attempts to wrie to a qemu-allocated page which is readable but write-protected. When I comment out mprotect in exec.c //mprotect(g2h(page_addr), qemu_host_page_size, // (prot & PAGE_BITS) & ~PAGE_WRITE); I can proceed further. I would guess mprotect is there for a reason so it doesn't seem like a good solution, besides the runs get substantially slower without mprotect. Is there a solution to this problem or a way to better understand what is going on? Thanks, Ilya Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
