Re: [Qemu-devel] kvm crashes with spice while loading qxl

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-04-26 10:53, Gerd Hoffmann wrote:
>   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?

Nope, this applies to both implementations.

> 
> 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

Cannot spot that quickly: In which way are they specific to qemu-kvm?

If they are, try to focus on upstream first. The qemu-kvm differences
are virtually deprecated, and I hope we can remove them really soon now
(my patches are all ready).

> 
>>   - 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 ...

Yeah, I can imagine...

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux