| Message ID | 54EF0504.6070401@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 26/02/2015 11:35, Paolo Bonzini wrote: > > > On 25/02/2015 18:16, Leon Alrae wrote: >> Hi, >> >> On 16/02/2015 18:17, Paolo Bonzini wrote: >>> This needs to go away sooner or later, but one complication is the >>> complex VFIO data structures that are modified in instance_finalize. >>> Take a shortcut for now. >> >> It looks like this commit introduced a race condition. QEMU segfaults >> very early in one of my tests where I boot Linux, and on one of my >> machines it's easier to reproduce than on the others. > > This should be enough to fix it. If it works for you I'll send a pull > request as soon as possible. > > diff --git a/cpus.c b/cpus.c > index 1cd9867..7bed67b 100644 > --- a/cpus.c > +++ b/cpus.c > @@ -1115,7 +1115,7 @@ bool qemu_in_vcpu_thread(void) > > void qemu_mutex_lock_iothread(void) > { > - if (!tcg_enabled()) { > + if (!tcg_enabled() || !first_cpu) { > qemu_mutex_lock(&qemu_global_mutex); > } else { > iothread_requesting_mutex = true; It works for me -- it fixes the crash, thanks. FYI I hit some other problem where QEMU stops responding (deadlock?) during a stress test quite randomly. The issue is most likely introduced by this commit (and above fix doesn't seem to be related). I'm going to look into that. Leon
On 26/02/2015 14:40, Leon Alrae wrote: > FYI I hit some other problem where QEMU stops responding (deadlock?) > during a stress test quite randomly. The issue is most likely introduced > by this commit (and above fix doesn't seem to be related). I'm going to > look into that. Hmm, I think I see what's going on. It's related to this commit. Paolo
diff --git a/cpus.c b/cpus.c index 1cd9867..7bed67b 100644 --- a/cpus.c +++ b/cpus.c @@ -1115,7 +1115,7 @@ bool qemu_in_vcpu_thread(void) void qemu_mutex_lock_iothread(void) { - if (!tcg_enabled()) { + if (!tcg_enabled() || !first_cpu) { qemu_mutex_lock(&qemu_global_mutex); } else { iothread_requesting_mutex = true;