From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMDIK-0007Mk-ST for qemu-devel@nongnu.org; Wed, 18 Sep 2013 04:39:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMDIE-0002T1-UQ for qemu-devel@nongnu.org; Wed, 18 Sep 2013 04:39:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMDIE-0002Su-M3 for qemu-devel@nongnu.org; Wed, 18 Sep 2013 04:39:26 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8I8dPkY029104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Sep 2013 04:39:25 -0400 Date: Wed, 18 Sep 2013 11:41:38 +0300 From: "Michael S. Tsirkin" Message-ID: <20130918084138.GA31069@redhat.com> References: <20130917162928.GA20672@redhat.com> <52388A3D.4090909@redhat.com> <20130917170752.GA20986@redhat.com> <52388E5F.6020802@redhat.com> <20130917172627.GA21064@redhat.com> <5238A859.9040705@redhat.com> <20130917195123.GB21419@redhat.com> <5238D18B.6020901@redhat.com> <20130918054848.GB23532@redhat.com> <523958E3.6020906@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <523958E3.6020906@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 00/38] Delay destruction of memory regions to instance_finalize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On Wed, Sep 18, 2013 at 09:40:19AM +0200, Paolo Bonzini wrote: > Il 18/09/2013 07:48, Michael S. Tsirkin ha scritto: > > So I think the fix is actually obeying ordering rules, > > that is know that write is in progress > > and flush on read. > > I think this can be modeled as a generic, synchronous > (*busmaster_cancel)(PCIDevice*) callback, that is called after bus > master is turned off. You don't even really have to wait for a read. Not really. Bus master is just an single instance of the bigger issue. It could be any device-specific register just as well. PCI reads and writes must obey ordering rules. ATM MMIO and DMA achieve this by using a single lock. If you want to move MMIO and DMA out of a common lock you must find some other way to force ordering. > > I think moving memory region destroy out to finalize makes sense > > irrespectively, as long as destroy is made idempotent so we can simply > > destroy everything without worrying whether we initialized it. > > > > The rest of the changes will be harder, we'll have to do > > them carefully on a case by case basis. > > Good, we are in agreement then. > > Paolo