From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ryan Harper <ryanh@us.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
yamahata@valinux.co.jp, "Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
Anthony Liguori <aliguori@linux.vnet.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: Mon, 8 Nov 2010 19:06:56 +0000 [thread overview]
Message-ID: <20101108190656.GG26714@redhat.com> (raw)
In-Reply-To: <20101108183901.GB22381@us.ibm.com>
On Mon, Nov 08, 2010 at 12:39:01PM -0600, Ryan Harper wrote:
> * Michael S. Tsirkin <mst@redhat.com> [2010-11-08 10:57]:
> > On Mon, Nov 08, 2010 at 08:02:50AM -0600, Ryan Harper wrote:
> > > * Markus Armbruster <armbru@redhat.com> [2010-11-08 06:04]:
> > > > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > > >
> > > > > On Mon, Nov 08, 2010 at 11:32:01AM +0100, Markus Armbruster wrote:
> >
> > Daniel, I'd like your input here: can you live with
> > device diappearing from info block and parsing
> > qdev tree info to figure out whether device is really gone?
>
> AFAICT, libvirt doesn't look at or use info block at all.
>
> I'd rather not have to add info block to libvirt; but currently I can't
> see how else we can determine if we should call drive_unplug if we do a
> device_del() and the guest removes it before we call drive_unplug().
>
> What happens is that the guest removes the device and when we call
> drive_unplug() it fails to find the target device (since it was deleted
> by the guest). Then we fail the PCiDelDisk and libvirt keeps the device
> config around even though the guest has finished removing it.
This needs drive_unplug to return an explicitly identifiable
'no such device' error code, which libvirt can catch and
ignore. Making the call to drive_unplug conditional on a
check to query-block/query-qdev is really a bug, because it
has an designed in race condition which means you need to
check for a 'no such device' error code regardless. So it
is better to just blindly call drive_unplug and handle the
non-fatal failure conditions every time - this ensures that
codepath gets exercised more frequently too :-)
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
next prev parent reply other threads:[~2010-11-08 19:07 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
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 [this message]
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=20101108190656.GG26714@redhat.com \
--to=berrange@redhat.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=ryanh@us.ibm.com \
--cc=stefan.hajnoczi@uk.ibm.com \
--cc=yamahata@valinux.co.jp \
/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.