[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: [Qemu-devel] Re: kvm crashes with spice while loading qxl
Date: Tue, 08 Mar 2011 11:17:52 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

On 03/07/2011 06:13 PM, Marcelo Tosatti wrote:
On Sun, Mar 06, 2011 at 12:38:44PM +0200, Avi Kivity wrote:
>  On 03/05/2011 06:35 PM, Marcelo Tosatti wrote:
>  >Regarding global mutex, TCG and KVM execution behaviour can become more
>  >similar wrt locking by dropping qemu_global_mutex during generation and
>  >execution of TBs.
>  How can you do that?  During generation, a device can assert the
>  reset line, changing cpu modes,

Writes to CPUState fields needs can moved to vcpu thread context
(run_on_cpu), and reads performed under a lock.

Good thing is most CPUState accesses are local to vcpu context.

That's a really good idea. And in fact that's what we do in kvm, if we have something to do to a cpu we queue it up in vcpu->requests and let the vcpu thread process it.

>   or move the memory map.

Memory map can be protected by a read-write lock initially, so that vcpu
thread holds it for read. Later can be converted to URCU.

rwlock is insufficient, need a way to force the vcpu off so a writer can actually do something.

So we need some kind of priority rwlock where a reader lets the lock know how it can force it off in case a writer comes along.

Is write access to memory map necessary from vcpu context?

Yes, examples writes to PCI BARs or the VGA windows at 0xa0000.

We can move them to a device thread, but the vcpu thread will have to wait for it (so it needs to drop any locks anyway).

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]