From: Ryan Harper <ryanh@us.ibm.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org,
Anthony Liguori <aliguori@linux.vnet.ibm.com>,
Ryan Harper <ryanh@us.ibm.com>,
Stefan Hajnoczi <stefan.hajnoczi@uk.ibm.com>
Subject: Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal
Date: Fri, 29 Oct 2010 10:03:36 -0500 [thread overview]
Message-ID: <20101029150336.GJ22904@us.ibm.com> (raw)
In-Reply-To: <m3sjzpjdfo.fsf@blackfin.pond.sub.org>
* Markus Armbruster <armbru@redhat.com> [2010-10-29 09:13]:
> [Note cc: Michael]
>
> Ryan Harper <ryanh@us.ibm.com> writes:
>
> > This patch series decouples the detachment of a block device from the removal
> > of the backing pci-device. Removal of a hotplugged pci device requires the
> > guest to respond before qemu tears down the block device. In some cases, the
> > guest may not respond leaving the guest with continued access to the block
> > device.
> >
> > The new monitor command, drive_unplug, will revoke a guests access to the
> > block device independently of the removal of the pci device.
> >
> > The first patch adds a new drive find method, the second patch implements the
> > monitor command and block layer changes.
> >
> > Changes since v3:
> > - Moved QMP command for drive_unplug() to separate patch
> >
> > Changes since v2:
> > - Added QMP command for drive_unplug()
> >
> > Changes since v1:
> > - CodingStyle fixes
> > - Added qemu_aio_flush() to bdrv_unplug()
> >
> > Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
>
> If I understand your patch correctly, the difference between your
> drive_unplug and my blockdev_del is as follows:
>
> * drive_unplug forcefully severs the connection between the host part of
> the block device and its BlockDriverState. A shell of the host part
> remains, to be cleaned up later. You need forceful disconnect
> operation to be able to revoke access to an image whether the guest
> cooperates or not. Fair enough.
>
> * blockdev_del deletes a host part. My current version fails when the
> host part is in use. I patterned that after netdev_del, which used to
> work that way, until commit 2ffcb18d:
>
> Make netdev_del delete the netdev even when it's in use
>
> To hot-unplug guest and host part of a network device, you do:
>
> device_del NIC-ID
> netdev_del NETDEV-ID
>
> For PCI devices, device_del merely tells ACPI to unplug the device.
> The device goes away for real only after the guest processed the ACPI
> unplug event.
>
> You have to wait until then (e.g. by polling info pci) before you can
> unplug the netdev. Not good.
>
> Fix by removing the "in use" check from do_netdev_del(). Deleting a
> netdev while it's in use is safe; packets simply get routed to the bit
> bucket.
>
> Isn't this the very same problem that's behind your drive_unplug?
Yes it is.
>
> I'd like to have some consistency among net, block and char device
> commands, i.e. a common set of operations that work the same for all of
> them. Can we agree on such a set?
Yeah; the current trouble (or at least what I perceive to be trouble) is
that in the case where the guest responds to device_del induced ACPI
removal event; the current qdev code already does the host-side device
tear down. Not sure if it is OK to do a blockdev_del() immediately
after the device_del. What happens when we do:
device_del
ACPI to guest
blockdev_del /* removes host-side device */
guest responds to ACPI
qdev calls pci device removal code
qemu attempts to destroy the associated host-side block
That may just work today; and if not, it shouldn't be hard to fix up the
code to check for NULLs
>
> Even if your drive_unplug shouldn't fit in that set, we might want it as
> a stop-gap. Depends on how urgent the need for it is. Yet another
> special-purpose command to be deprecated later.
The fix is urgent; but I'm willing to spin a couple patches if it helps
get this into better shape.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com
next prev parent reply other threads:[~2010-10-29 15:03 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-25 18:22 [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal Ryan Harper
2010-10-25 18:22 ` [Qemu-devel] [PATCH 1/3] v2 Add drive_get_by_id Ryan Harper
2010-10-29 13:18 ` Markus Armbruster
2010-10-25 18:22 ` [Qemu-devel] [PATCH 2/3] v2 Fix Block Hotplug race with drive_unplug() Ryan Harper
2010-10-29 14:01 ` Markus Armbruster
2010-10-29 14:15 ` Anthony Liguori
2010-10-29 14:29 ` Kevin Wolf
2010-10-29 14:40 ` Anthony Liguori
2010-10-29 14:57 ` Kevin Wolf
2010-10-29 15:28 ` Anthony Liguori
2010-10-29 16:08 ` Kevin Wolf
2010-10-30 13:25 ` Christoph Hellwig
2010-10-29 15:28 ` Markus Armbruster
2010-11-01 21:06 ` Ryan Harper
2010-10-25 18:22 ` [Qemu-devel] [PATCH 3/3] Add qmp version of drive_unplug Ryan Harper
2010-10-29 14:12 ` [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal Markus Armbruster
2010-10-29 15:03 ` Ryan Harper [this message]
2010-10-29 16:10 ` Markus Armbruster
2010-10-29 16:50 ` Ryan Harper
2010-11-02 9:40 ` Markus Armbruster
2010-11-02 13:22 ` Michael S. Tsirkin
2010-11-02 13:41 ` Kevin Wolf
2010-11-02 13:46 ` Ryan Harper
2010-11-02 13:58 ` Michael S. Tsirkin
2010-11-02 14:22 ` Ryan Harper
2010-11-02 15:46 ` Michael S. Tsirkin
2010-11-02 16:53 ` Ryan Harper
2010-11-02 17:59 ` Michael S. Tsirkin
2010-11-02 19:01 ` Ryan Harper
2010-11-02 19:17 ` Michael S. Tsirkin
2010-11-02 20:23 ` Ryan Harper
2010-11-03 7:21 ` Michael S. Tsirkin
2010-11-03 12:04 ` Ryan Harper
2010-11-03 16:41 ` Markus Armbruster
2010-11-03 17:29 ` Ryan Harper
2010-11-03 18:02 ` Michael S. Tsirkin
2010-11-03 20:59 ` Ryan Harper
2010-11-03 21:26 ` Michael S. Tsirkin
2010-11-04 16:45 ` Ryan Harper
2010-11-04 17:04 ` Michael S. Tsirkin
2010-11-05 13:27 ` Markus Armbruster
2010-11-05 14:17 ` Michael S. Tsirkin
2010-11-05 14:29 ` Ryan Harper
2010-11-05 16:01 ` Markus Armbruster
2010-11-08 21:02 ` Michael S. Tsirkin
2010-11-05 14:25 ` Ryan Harper
2010-11-05 16:10 ` Markus Armbruster
2010-11-05 16:22 ` Ryan Harper
2010-11-06 8:18 ` Markus Armbruster
2010-11-08 2:19 ` Ryan Harper
2010-11-08 10:32 ` Markus Armbruster
2010-11-08 10:49 ` Michael S. Tsirkin
2010-11-08 12:03 ` Markus Armbruster
2010-11-08 14:02 ` Ryan Harper
2010-11-08 16:56 ` Michael S. Tsirkin
2010-11-08 17:04 ` Daniel P. Berrange
2010-11-08 18:41 ` Ryan Harper
2010-11-08 18:39 ` Ryan Harper
2010-11-08 19:06 ` Daniel P. Berrange
2010-11-08 16:34 ` Michael S. Tsirkin
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=20101029150336.GJ22904@us.ibm.com \
--to=ryanh@us.ibm.com \
--cc=aliguori@linux.vnet.ibm.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=mst@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).