From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRQIO-00031F-Qe for qemu-devel@nongnu.org; Thu, 25 Oct 2012 12:28:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRQIN-0003oD-Ia for qemu-devel@nongnu.org; Thu, 25 Oct 2012 12:28:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRQIN-0003o8-9w for qemu-devel@nongnu.org; Thu, 25 Oct 2012 12:28:35 -0400 Message-ID: <508968AB.2040704@redhat.com> Date: Thu, 25 Oct 2012 18:28:27 +0200 From: Avi Kivity 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> <508798D9.2070406@redhat.com> In-Reply-To: <508798D9.2070406@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: Paolo Bonzini Cc: Liu Ping Fan , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Anthony Liguori , Jan Kiszka On 10/24/2012 09:29 AM, Paolo Bonzini wrote: > 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. I meant, as an unrealistic example, hot-unplugging the bridge itself. So we have a callback that updates information in the bridge (up register state) being called asynchronously. A more realistic example would be hot-unplug of an HBA, then the block layer callback comes back to update the device. So stop_machine() would need to cancel all I/O and wait for I/O that cannot be cancelled. > > 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) ^ long latency > 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. > Maybe my worry about long stop_machine latencies is premature. Everyone in the kernel hates it, but the kernel scales a lot more than qemu and is in a much better place wrt threading. -- error compiling committee.c: too many arguments to function