[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] kvm crashes with spice while loading qxl
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] kvm crashes with spice while loading qxl |
Date: |
Tue, 26 Apr 2011 11:06:13 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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