From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58457 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P92pf-0004gV-PD for qemu-devel@nongnu.org; Thu, 21 Oct 2010 17:37:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P92pe-0000Eb-Pi for qemu-devel@nongnu.org; Thu, 21 Oct 2010 17:37:55 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:38252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P92pe-0000EN-KJ for qemu-devel@nongnu.org; Thu, 21 Oct 2010 17:37:54 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9LLS6IZ027779 for ; Thu, 21 Oct 2010 15:28:06 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9LLbpYi210560 for ; Thu, 21 Oct 2010 15:37:51 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9LLbo7r019134 for ; Thu, 21 Oct 2010 15:37:51 -0600 Date: Thu, 21 Oct 2010 16:37:46 -0500 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH 2/2] v2 Fix Block Hotplug race with drive_unplug() Message-ID: <20101021213746.GK22904@us.ibm.com> References: <1287498749-10400-1-git-send-email-ryanh@us.ibm.com> <1287498749-10400-3-git-send-email-ryanh@us.ibm.com> <20101021132738.GM27578@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101021132738.GM27578@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Stefan Hajnoczi , Anthony Liguori , Ryan Harper , qemu-devel@nongnu.org, Kevin Wolf * Daniel P. Berrange [2010-10-21 08:29]: > On Tue, Oct 19, 2010 at 09:32:29AM -0500, Ryan Harper wrote: > > Block hot unplug is racy since the guest is required to acknowlege the ACPI > > unplug event; this may not happen synchronously with the device removal command > > > > This series aims to close a gap where by mgmt applications that assume the > > block resource has been removed without confirming that the guest has > > acknowledged the removal may re-assign the underlying device to a second guest > > leading to data leakage. > > > > This series introduces a new montor command to decouple asynchornous device > > removal from restricting guest access to a block device. We do this by creating > > a new monitor command drive_unplug which maps to a bdrv_unplug() command which > > does a qemu_aio_flush; bdrv_flush() and bdrv_close(). Once complete, subsequent > > IO is rejected from the device and the guest will get IO errors but continue to > > function. > > > > A subsequent device removal command can be issued to remove the device, to which > > the guest may or maynot respond, but as long as the unplugged bit is set, no IO > > will be sumbitted. > > The name 'drive_unplug' suggests to me that the drive object is > not being deleted/free()d ? Is that correct understanding, and if > so, what is responsible for finally free()ing the drive backend ? It's technically the BlockDriverState Driver that we're closing. To fully release the remaining resources, a device_del is required (which of course requires guest participation with the current interface). Once QEMU issues the removal request, the guest responds and the piix4 acpi handler for pciej_write writes invokes qdev_free() on the target device. qdev_free() on the pci device will make it's way to the qdev exit handler registered for virtio-blk devices, virtio_blk_exit_pci(). virtio_blk_exit_pci() marks the drive structure for deletion. When qdev calls the properties handler, it invokes free_drive() on the disk and that calls blockdev_auto_del() which will do a bdrv_delete() which nukes the remaining objects (the acutal BlockDriverState). I think I got the whole path in there. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com