From: Eric Blake <eblake@redhat.com>
To: John Snow <jsnow@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, qemu-block@nongnu.org, quintela@redhat.com,
jcody@redhat.com, dgilbert@redhat.com, amit.shah@redhat.com,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] migration: disallow migrate_add_blocker during migration
Date: Fri, 9 Oct 2015 13:42:21 -0600 [thread overview]
Message-ID: <5618189D.4030600@redhat.com> (raw)
In-Reply-To: <1443632849-10940-1-git-send-email-jsnow@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3467 bytes --]
On 09/30/2015 11:07 AM, John Snow wrote:
> If a migration is already in progress and somebody attempts
> to add a migration blocker, this should rightly fail.
>
> Add an errp parameter and a retcode return value to migrate_add_blocker.
>
> This is part one of two for a solution to prohibit e.g. block jobs
> from running concurrently with migration.
And should be independently useful, whether or not part 2 is taken.
>
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
> +++ b/hw/misc/ivshmem.c
> @@ -740,7 +740,10 @@ static int pci_ivshmem_init(PCIDevice *dev)
> if (s->role_val == IVSHMEM_PEER) {
> error_setg(&s->migration_blocker,
> "Migration is disabled when using feature 'peer mode' in device 'ivshmem'");
> - migrate_add_blocker(s->migration_blocker);
> + if (migrate_add_blocker(s->migration_blocker, NULL) < 0) {
> + error_report("Unable to prohibit migration during ivshmem init");
> + exit(1);
> + }
Marc-André has been trying to get rid of exit(1) calls here, but this
matched the style at the time you wrote it.
> +++ b/hw/scsi/vhost-scsi.c
> @@ -239,8 +239,14 @@ static void vhost_scsi_realize(DeviceState *dev, Error **errp)
> vhost_dummy_handle_output);
> if (err != NULL) {
> error_propagate(errp, err);
> - close(vhostfd);
> - return;
> + goto close_fd;
> + }
> +
> + error_setg(&s->migration_blocker,
> + "vhost-scsi does not support migration");
Indentation looks unusual...
> @@ -262,9 +268,16 @@ static void vhost_scsi_realize(DeviceState *dev, Error **errp)
> /* Note: we can also get the minimum tpgt from kernel */
> s->target = vs->conf.boot_tpgt;
>
> - error_setg(&s->migration_blocker,
> - "vhost-scsi does not support migration");
...although it was merely preserved across code motion. You may still
want to fix it, though.
> +++ b/hw/virtio/vhost.c
> @@ -926,13 +926,25 @@ int vhost_dev_init(struct vhost_dev *hdev, void *opaque,
> goto fail;
> }
>
> - for (i = 0; i < hdev->nvqs; ++i) {
> - r = vhost_virtqueue_init(hdev, hdev->vqs + i, hdev->vq_index + i);
> - if (r < 0) {
> - goto fail_vq;
> - }
> - }
> hdev->features = features;
> + hdev->migration_blocker = NULL;
> +
> + if (!(hdev->features & (0x1ULL << VHOST_F_LOG_ALL))) {
> + error_setg(&hdev->migration_blocker,
> + "Migration disabled: vhost lacks VHOST_F_LOG_ALL feature.");
error_setg() messages shouldn't end in '.', although this is once again
code motion. As before, you could fix it up.
> +++ b/stubs/migr-blocker.c
> @@ -1,8 +1,9 @@
> #include "qemu-common.h"
> #include "migration/migration.h"
>
> -void migrate_add_blocker(Error *reason)
> +int migrate_add_blocker(Error *reason, Error **errp)
> {
> + return 0;
Should this set errp and return -EBUSY, so that callers don't assume
that their blocker is effective when you really ignored the blocker?
Then again, pre-patch, you silently ignored the blocker, so I guess it's
not much worse in semantics.
I spotted some minor things, but am comfortable with:
Reviewed-by: Eric Blake <eblake@redhat.com>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2015-10-09 19:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 17:07 [Qemu-devel] [PATCH v2] migration: disallow migrate_add_blocker during migration John Snow
2015-10-09 17:55 ` Dr. David Alan Gilbert
2015-10-09 19:42 ` Eric Blake [this message]
2015-10-09 19:53 ` John Snow
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=5618189D.4030600@redhat.com \
--to=eblake@redhat.com \
--cc=amit.shah@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jcody@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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).