|
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:1.9.2.13) 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
[Prev in Thread] | Current Thread | [Next in Thread] |