From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=57664 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PwBMV-0006AH-JA
	for qemu-devel@nongnu.org; Sun, 06 Mar 2011 05:38:56 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1PwBMU-0007ms-EW
	for qemu-devel@nongnu.org; Sun, 06 Mar 2011 05:38:55 -0500
Received: from mx1.redhat.com ([209.132.183.28]:26544)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1PwBMU-0007lt-0G
	for qemu-devel@nongnu.org; Sun, 06 Mar 2011 05:38:54 -0500
Message-ID: <4D736434.1030704@redhat.com>
Date: Sun, 06 Mar 2011 12:38:44 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <AANLkTint9-P-1jD5pbXstzPcYueLHQ68Rd0T_Chz6xRN@mail.gmail.com>
	<4D68F20D.2020401@web.de> <20110305163558.GA4607@amt.cnet>
In-Reply-To: <20110305163558.GA4607@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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>, xming <xmingske@gmail.com>, Jan Kiszka <jan.kiszka@web.de>, Gerd Hoffmann <kraxel@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>

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, or move the memory map.

During execution, tcg accesses memory a lot.  So we'll need to acquire 
qemu_global_mutex for every memory access, and separate protection for TB.

kvm achieves lockless protection by forcing vcpus off and dropping their 
page tables while executing natively, and using srcu while emulating.  
We can do something similar for tcg, but it won't be easy.

> Of course for memory or PIO accesses from vcpu context qemu_global_mutex
> must be acquired.

Yes, and not just mmio - all memory accesses.

> 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.
>
>
>   21.62%               sh            3d38920b3f  [.] 0x00003d38920b3f
>    6.38%               sh  qemu-system-x86_64    [.] phys_page_find_alloc

should be replaced by a memslot list probably

>    4.90%               sh  qemu-system-x86_64    [.] tb_find_fast
>    4.34%               sh  qemu-system-x86_64    [.] tlb_flush
>


-- 
error compiling committee.c: too many arguments to function