qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: dgilbert@redhat.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] unplug_request and migration
Date: Thu, 08 Jun 2017 18:07:31 +0200	[thread overview]
Message-ID: <87o9tya2f0.fsf@secure.mitica> (raw)
In-Reply-To: <20170608144106.GG25805@umbus.fritz.box> (David Gibson's message of "Fri, 9 Jun 2017 00:41:06 +1000")

David Gibson <david@gibson.dropbear.id.au> wrote:
> Hi Dave & Juan,
>
> I'm hoping one of you can answer this.
>
> I'm currently grappling with (amongst other things) a pseries machine
> racing a hot unplug operation with a migrate.  There's various issues
> with what interim state we need, and which bits of it need to be
> migrated that I'm still investigating.  But, there's a more general
> question that I'm guessing must have already been addressed for x86.
>
> For any "soft" unplug device - i.e. using ->unplug_request, rather
> than ->unplug, giving a device_del command will just ask the guest
> nicely to release the device, with the completion of the unplug
> happening only if and when the guest indicates it's ready for the
> device to go away.  AFAICT, the device_del command will return as soon
> as the request is made, but if the guest is busy, the completion of
> the hot unplug could take arbitrarily long.
>
> So, what happens if there's a migration in between the unplug_request
> and the guest completing the unplug?  How does libvirt (or whatever)
> know whether to include the device on the destination machine command
> line?

On upstream, I removed the posibility of doing a hotplug/unplug while we
are migrating.  But if device del has returned, I can't see how that can
be detected.

Later, Juan.

  parent reply	other threads:[~2017-06-08 16:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08 14:41 [Qemu-devel] unplug_request and migration David Gibson
2017-06-08 15:10 ` Dr. David Alan Gilbert
2017-06-08 15:44   ` Dr. David Alan Gilbert
2017-06-08 16:07 ` Juan Quintela [this message]
2017-06-09  9:09 ` Igor Mammedov
2017-06-09 10:03   ` David Gibson
2017-06-09 12:18     ` Juan Quintela

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=87o9tya2f0.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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).