[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] unplug_request and migration
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-ppc] unplug_request and migration |
Date: |
Thu, 8 Jun 2017 16:10:20 +0100 |
User-agent: |
Mutt/1.8.2 (2017-04-18) |
* David Gibson (address@hidden) 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?
No, I don't understand how that works. cc'ing in jdenemar for libvirt
Dave
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_
> _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK