From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQvPF-0005hL-Gc for qemu-devel@nongnu.org; Wed, 24 Oct 2012 03:29:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TQvPB-0005Xx-BJ for qemu-devel@nongnu.org; Wed, 24 Oct 2012 03:29:37 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:33177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQvPB-0005Xo-4n for qemu-devel@nongnu.org; Wed, 24 Oct 2012 03:29:33 -0400 Received: by mail-wg0-f53.google.com with SMTP id dr1so125201wgb.10 for ; Wed, 24 Oct 2012 00:29:32 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <508798D9.2070406@redhat.com> Date: Wed, 24 Oct 2012 09:29:29 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1350897839-29593-1-git-send-email-pingfank@linux.vnet.ibm.com> <1350897839-29593-6-git-send-email-pingfank@linux.vnet.ibm.com> <5085140F.2070603@redhat.com> <508684BE.1080103@redhat.com> <508685C0.60700@redhat.com> <5086862A.1060307@redhat.com> <5086875F.7010108@redhat.com> <50868851.1070806@redhat.com> <50868A71.4090603@redhat.com> <50868E43.2060403@redhat.com> <5086AE70.9000105@redhat.com> <5086B708.6000209@redhat.com> <5086C12D.8000009@redhat.com> In-Reply-To: <5086C12D.8000009@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Liu Ping Fan , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Anthony Liguori , Jan Kiszka Il 23/10/2012 18:09, Avi Kivity ha scritto: >> But our interfaces had better support asynchronicity, and indeed they >> do: after you write to the "eject" register, the "up" will show the >> device as present until after destroy is done. This can be changed to >> show the device as present only until after step 4 is done. > > Let's say we want to eject the hotplug hardware itself (just as an > example). With refcounts, the callback that updates "up" will hold on > to to it via refcounts. With stop_machine(), you need to cancel that > callback, or wait for it somehow, or it can arrive after the > stop_machine() and bite you. The callback that updates "up" is for the parent of the hotplug hardware. There is nothing that has to be updated in the hotplug hardware itself. Updating the "up" register is the final part of isolate(), and runs before the stop_machine(). The steps above can be further refined like this: 4a. close all backends (also cancel or complete all pending I/O) 4b. notify parent that we're done 4ba. parent removes device from its bus 4bb. parent notifies guest 4bc. parent schedules stop_machine(qdev_free(child)) 5. a bottom half calls stop_machine(qdev_free(child)) If unplugging a whole sub-tree, the parent can notify its own parent at the end of 4b. Because the only purpose of stop_machine is to quiesce subsystems not affected by step 4 (timer+memory, typically), destructions can be done in any order and even intermixed with executions of 4b for the parent. In the beginning the only asynchronous step would be 5. If the need arises we can use continuation-passing to make all the preceding steps asynchronous too. >>> We may also want notification after step 4 (or 5); if the device holds >>> some host resource someone may want to know that it is ready for reuse. >> >> I think guest notification should be after (4), while management >> notification should be after (5). > Yes. After (2) we can return from the eject mmio. Agreed. Paolo