From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVLvS-0004tN-2h for qemu-devel@nongnu.org; Mon, 05 Nov 2012 07:37:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TVLvN-0004ap-Rq for qemu-devel@nongnu.org; Mon, 05 Nov 2012 07:37:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVLvN-0004af-ID for qemu-devel@nongnu.org; Mon, 05 Nov 2012 07:37:05 -0500 Message-ID: <5097B2EA.6000907@redhat.com> Date: Mon, 05 Nov 2012 14:36:58 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1351468127-15025-1-git-send-email-pingfank@linux.vnet.ibm.com> <1351468127-15025-6-git-send-email-pingfank@linux.vnet.ibm.com> <508E4D45.5060106@redhat.com> <50929902.9050002@redhat.com> <5092C2FF.5070909@web.de> <50937DB2.3040302@web.de> In-Reply-To: <50937DB2.3040302@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [patch v5 5/8] memory: introduce local lock for address space List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , Stefan Hajnoczi , Marcelo Tosatti , liu ping fan , qemu-devel@nongnu.org, Anthony Liguori , Paolo Bonzini On 11/02/2012 10:00 AM, Jan Kiszka wrote: > > > >> As I understand the series, as->lock == NULL means that we will never > >> take any lock during dispatch as the caller is not yet ready for > >> fine-grained locking. This prevents the problem - for PIO at least. But > >> this series should break TCG as it calls into MMIO dispatch from the > >> VCPU while holding the BQL. > >> > > What about add another condition "dispatch_type == DISPATCH_MMIO" to > > tell this situation. > > An alternative pattern that we will also use for core services is to > provide an additional entry point, one that indicates that the caller > doesn't hold the BQL. Then we will gradually move things over until the > existing entry point is obsolete. > I like it (or rather, least dislike it). So we'd have address_space_rw() and address_space_rw_unlocked() (or maybe, address_space_rw() and address_space_rw_locked(), to indicate the preferred way of doing things). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.