On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote:
> On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote:
> > On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan Gilbert wrote:
> > > * Jens Freimann (jfreim...@redhat.com) wrote:
[...]
> > > > + }
> > > > + if (migration_in_setup(s) && !should_be_hidden && n->primary_dev) {
> > > > + qdev_unplug(n->primary_dev, &err);
> > >
> > > Not knowing unplug well; can you just explain - is that device hard
> > > unplugged and it's gone by the time this function returns or is it still
> > > hanging around for some indeterminate time?
>
> Qemu will trigger an unplug request via pcie attention button in which case
> there could be a delay by the guest operating system. We could give it some
> amount of time and if nothing happens try surpise removal or handle the
> error otherwise.
I'm missing something here:
Isn't the whole point of the new device-hiding infrastructure to
prevent QEMU from closing the VFIO until migration ended
successfully?
What exactly is preventing QEMU from closing the host VFIO device
after the guest OS has handled the unplug request?
--
Eduardo
