From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: kvm crashes with spice while loading qxl Date: Sat, 05 Mar 2011 18:11:41 +0100 Message-ID: <4D726ECD.1010707@redhat.com> References: <4D68F20D.2020401@web.de> <20110305163558.GA4607@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 , Avi Kivity To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:9739 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753833Ab1CERLr (ORCPT ); Sat, 5 Mar 2011 12:11:47 -0500 In-Reply-To: <20110305163558.GA4607@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 03/05/2011 05:35 PM, Marcelo Tosatti wrote: > TCG and KVM execution behaviour can become more > similar wrt locking by dropping qemu_global_mutex during generation and > execution of TBs. > > Of course for memory or PIO accesses from vcpu context qemu_global_mutex > must be acquired. -icount already has most of the machinery needed for this. At this point, I think people interested in TCG should choose between staying with legacy and gaining a bit more speed for uniprocessor simulation, or following KVM with a more complex architecture and finer-grained locking---but also a more future-proof design. BTW, I'll post soon patches for iothread -icount that work (at least in my tests), are much simpler than anything I posted so far, and hopefully will show that iothread is not fundamentally incompatible with anything (and in fact can simplify things much more than complicate them). > With that in place, it becomes easier to justify further improvements > regarding parallelization, such as using a read-write lock for > l1_phys_map / phys_page_find_alloc. Or URCU (userspace RCU), too. Paolo