From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLy7X-0008Ud-K7 for qemu-devel@nongnu.org; Tue, 17 Sep 2013 12:27:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLy7R-0003Oo-K9 for qemu-devel@nongnu.org; Tue, 17 Sep 2013 12:27:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLy7R-0003Oi-Bk for qemu-devel@nongnu.org; Tue, 17 Sep 2013 12:27:17 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8HGRGPw004918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Sep 2013 12:27:16 -0400 Date: Tue, 17 Sep 2013 19:29:28 +0300 From: "Michael S. Tsirkin" Message-ID: <20130917162928.GA20672@redhat.com> References: <1378211609-16121-1-git-send-email-pbonzini@redhat.com> <20130917124724.GA18965@redhat.com> <52386A29.9090908@redhat.com> <20130917144541.GA19882@redhat.com> <52387840.8090405@redhat.com> <20130917155909.GA20460@redhat.com> <52387FBF.4050504@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52387FBF.4050504@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 Tue, Sep 17, 2013 at 06:13:51PM +0200, Paolo Bonzini wrote: > Il 17/09/2013 17:59, Michael S. Tsirkin ha scritto: > > Yes but just not freeing it is unlikely to be enough. > > We need to make sure data structures are consistent. > > So this really needs to be done carefully, device by device. > > Of course. I checked SCSI already and it's sane. > > >>>> - del_vm_change_state_handler > >> > >> Same here: user can stop/cont between exit and finalize, for example > >> because the I/O failed. > > > > Device that is not guest visible is very unlikely to > > care about whether guest is running. > > Most devices do not care at all whether the guest is running. :) If > they do, they usually just use vm_clock. > > But retrying failed I/O uses qemu_add_vm_change_set_handler, and that > has to be done even after the device is not guest visible anymore. > > BTW, qemu_del_nic is another one that I forgot to mention. You could > have MMIO that triggers a transmit while the device is going down, for > example. > > Paolo Wait a second. This API simply does not make sense. If region is not visible it's MMIO really mustn't trigger, exit or no exit. Disabling region and still getting op callbacks afterwards is not what any caller of this API expects. I'm not sure what to do about the bounce buffer thing but it needs to be fixed some other way without breaking API. -- MST