* Avi Kivity [EMAIL PROTECTED] [2008-04-26 02:23]:
Please reuse qemu_mutex for this, no need for a new one.
I'm having a little trouble wrapping my head around all of the locking
here. If I avoid qemu_mutex and use a new one, I've got everything
working. However, attemping to use qemu_mutex
Ryan Harper wrote:
* Avi Kivity [EMAIL PROTECTED] [2008-04-26 02:23]:
Please reuse qemu_mutex for this, no need for a new one.
I'm having a little trouble wrapping my head around all of the locking
here. If I avoid qemu_mutex and use a new one, I've got everything
working.
Ryan Harper wrote:
There is a race between when the vcpu thread issues a create ioctl and when
apic_reset() gets called resulting in getting a badfd error.
The problem is indeed there, but the fix is wrong:
main threadvcpu thread
diff --git a/qemu/qemu-kvm.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Harper wrote:
+/* block until cond_wait occurs */
+pthread_mutex_lock(vcpu_mutex);
+/* now we can signal */
+pthread_cond_signal(qemu_vcpuup_cond);
+pthread_mutex_unlock(vcpu_mutex);
It is not necessary to take the mutex
Ulrich Drepper wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Harper wrote:
@@ -388,9 +395,10 @@ static void kvm_add_signal(struct qemu_kvm_signal_table
*sigtab, int signum)
void kvm_init_new_ap(int cpu, CPUState *env)
{
+pthread_mutex_lock(vcpu_mutex);
There is a race between when the vcpu thread issues a create ioctl and when
apic_reset() gets called resulting in getting a badfd error.
main threadvcpu thread
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 78127de..3513e8c 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
* Ryan Harper [EMAIL PROTECTED] [2008-04-26 00:27]:
There is a race between when the vcpu thread issues a create ioctl and when
apic_reset() gets called resulting in getting a badfd error.
main threadvcpu thread
guilt refresh clipped my text short.
main thread
