Oops forgot to send this to the list too, here we go > That's a spice bug. In fact, there are a lot of > qemu_mutex_lock/unlock_iothread in that subsystem. I bet at least a few > of them can cause even more subtle problems. Just tried spice 0.7.3 (was using 0.6.x) and still the same, should I file a bug against spice? > Two general issues with dropping the global mutex like this: > Â- The caller of mutex_unlock is responsible for maintaining > Â cpu_single_env across the unlocked phase (that's related to the > Â abort above). > Â- Dropping the lock in the middle of a callback is risky. That may > Â enable re-entrances of code sections that weren't designed for this > Â (I'm skeptic about the side effects of > Â qemu_spice_vm_change_state_handler - why dropping the lock here?). > > Spice requires a careful review regarding such issues. Or it should > pioneer with introducing its own lock so that we can handle at least > related I/O activities over the VCPUs without holding the global mutex > (but I bet it's not the simplest candidate for such a new scheme). > > Jan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
