Hi,
[ ... back online now ... ]
/var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.14.0/qemu-kvm.c:1724:
kvm_mutex_unlock: Assertion `!cpu_single_env' failed.
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.
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).
This is true for qemu-kvm only, right?
qemu-kvm specific patches which add the cpu_single_env tracking (not
polished yet) are here:
http://cgit.freedesktop.org/spice/qemu/log/?h=spice.kvm.v28
- 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
Hmm, indeed.
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).
spice/qxl used to have its own locking scheme. That didn't work out
though. spice server is threaded and calls back into qxl from spice
thread context, and some of these callbacks need access to qemu data
structures (display surface) and thus lock protection which covers more
than just the spice subsystem.
I'll look hard again whenever I can find a way out of this (preferably
drop the need for the global lock somehow). For now I'm pretty busy
with the email backlog though ...
cheers,
Gerd
--
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
