From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46576 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwt3L-0007ZV-BU for qemu-devel@nongnu.org; Tue, 08 Mar 2011 04:18:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pwt3J-0000qb-DY for qemu-devel@nongnu.org; Tue, 08 Mar 2011 04:18:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pwt3J-0000qP-1f for qemu-devel@nongnu.org; Tue, 08 Mar 2011 04:18:01 -0500 Message-ID: <4D75F440.6010401@redhat.com> Date: Tue, 08 Mar 2011 11:17:52 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4D68F20D.2020401@web.de> <20110305163558.GA4607@amt.cnet> <4D736434.1030704@redhat.com> <20110307161305.GB10021@amt.cnet> In-Reply-To: <20110307161305.GB10021@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: kvm crashes with spice while loading qxl List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: kvm@vger.kernel.org, qemu-devel , xming , Jan Kiszka , Gerd Hoffmann , Paolo Bonzini 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