[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] unplug_request and migration
From: |
Juan Quintela |
Subject: |
Re: [Qemu-ppc] unplug_request and migration |
Date: |
Thu, 08 Jun 2017 18:07:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
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?
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.