All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Harper <ryanh@us.ibm.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Stefan Hajnoczi <stefan.hajnoczi@uk.ibm.com>,
	Anthony Liguori <aliguori@linux.vnet.ibm.com>,
	Ryan Harper <ryanh@us.ibm.com>,
	qemu-devel@nongnu.org, Kevin Wolf <kwolf@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] v2 Fix Block Hotplug race with drive_unplug()
Date: Thu, 21 Oct 2010 16:37:46 -0500	[thread overview]
Message-ID: <20101021213746.GK22904@us.ibm.com> (raw)
In-Reply-To: <20101021132738.GM27578@redhat.com>

* Daniel P. Berrange <berrange@redhat.com> [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

  reply	other threads:[~2010-10-21 21:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-19 14:32 [Qemu-devel] [PATCH 0/2] v2 Decouple block device removal from device removal Ryan Harper
2010-10-19 14:32 ` [Qemu-devel] [PATCH 1/2] v2 Add drive_get_by_id Ryan Harper
2010-10-19 14:32 ` [Qemu-devel] [PATCH 2/2] v2 Fix Block Hotplug race with drive_unplug() Ryan Harper
2010-10-19 15:21   ` Stefan Hajnoczi
2010-10-21 13:27   ` Daniel P. Berrange
2010-10-21 21:37     ` Ryan Harper [this message]
2010-10-22  8:10       ` Daniel P. Berrange
2010-10-22 10:31       ` Kevin Wolf
2010-10-29 13:33         ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101021213746.GK22904@us.ibm.com \
    --to=ryanh@us.ibm.com \
    --cc=aliguori@linux.vnet.ibm.com \
    --cc=berrange@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefan.hajnoczi@uk.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.