From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: kvm crashes with spice while loading qxl Date: Tue, 08 Mar 2011 11:17:52 +0200 Message-ID: <4D75F440.6010401@redhat.com> References: <4D68F20D.2020401@web.de> <20110305163558.GA4607@amt.cnet> <4D736434.1030704@redhat.com> <20110307161305.GB10021@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , xming , Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel , Paolo Bonzini To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:31167 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751649Ab1CHJSB (ORCPT ); Tue, 8 Mar 2011 04:18:01 -0500 In-Reply-To: <20110307161305.GB10021@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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