On Sun, Apr 06, 2008 at 12:15:07PM +0300, Avi Kivity wrote: > Marcelo Tosatti wrote: > >Otherwise a signal can be received in userspace and a vcpu goes back > >to the kernel while it should stay still. > > > >Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> > > > >Index: kvm-userspace.io/qemu/qemu-kvm.c > >=================================================================== > >--- kvm-userspace.io.orig/qemu/qemu-kvm.c > >+++ kvm-userspace.io/qemu/qemu-kvm.c > >@@ -350,7 +350,6 @@ static void *ap_main_loop(void *_env) > > vcpu->env = env; > > vcpu->env->thread_id = kvm_get_thread_id(); > > sigfillset(&signals); > >- sigdelset(&signals, SIG_IPI); > > sigprocmask(SIG_BLOCK, &signals, NULL); > > kvm_create_vcpu(kvm_context, env->cpu_index); > > kvm_qemu_init_env(env); > > > > > > Does this work with -no-kvm-irqchip?
Yes. SIG_IPI was blocked before the IO thread. > I think we need to fix the kernel to handle random signals. Otherwise > even attaching a debugger can change guest behavior (I think). Well ptrace forces signals so SIGSTOP is delivered even though the child has blocked them. Attaching a debugger does change behaviour since SIGSTOP will send a vcpu back to userspace. Can you be more specific? ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
