From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop Date: Thu, 28 Jun 2012 18:12:57 +0300 Message-ID: <4FEC7479.5000509@redhat.com> References: <4FE4F56D.1020201@web.de> <4FE4F7F5.7030400@web.de> <20120626193420.GA19852@amt.cnet> <4FEC65DF.20504@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Jan Kiszka , Liu Ping Fan , kvm , qemu-devel , Alexander Graf To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20513 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751459Ab2F1POC (ORCPT ); Thu, 28 Jun 2012 11:14:02 -0400 In-Reply-To: <4FEC65DF.20504@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 06/28/2012 05:10 PM, Anthony Liguori wrote: >> >> 1. read_lock(memmap_lock) >> 2. MemoryRegionSection mrs = lookup(addr) >> 3. qom_ref(mrs.mr->dev) >> 4. read_unlock(memmap_lock) >> >> 5. mutex_lock(dev->lock) >> 6. dispatch(&mrs, addr, data, size) >> 7. mutex_unlock(dev->lock) > > Just a detail, I don't think we should acquire a device specific lock in > global code. Rather, I think we should acquire the global lock before > dispatch unless a MemoryRegion is marked as being unlocked. I think I agree. The mutex acquisition is moved inside dispatch (in device-specific code). A side effect is that device code must not call memory_region_destroy() outside its constructor or destructor. -- error compiling committee.c: too many arguments to function