Re: [Qemu-ppc] [Qemu-devel] [PATCH] spapr: manage hotplugged devices while the VM is not started

[Marcel Apfelbaum]

On 16/06/2017 16:53, Igor Mammedov wrote:
> On Wed, 14 Jun 2017 19:27:12 -0500
> Michael Roth <address@hidden> wrote:
>
> > Quoting Igor Mammedov (2017-06-14 04:00:01)
> > > On Tue, 13 Jun 2017 16:42:45 -0500
> > > Michael Roth <address@hidden> wrote:
> > >    
> > > > Quoting Igor Mammedov (2017-06-09 03:27:33)

[...]

> > But that raises a 2nd point. Our dilemma isn't that we can't
> > rely on dev->hotplugged being synchronized (though if it
> > was we could build something around that), our dilemma is
> > that we make the following assumption in our code:
> >
> > "Devices present at start-time will be handled the same way,
> > on source or dest, regardless of whether they were added via
> > cmdline or via device_add prior to machine start / migration
> > stream processing."
> >
> > And I think that's a sensible expectation, since in theory
> > even the source could build up a machine via device_add
> > prior to starting it, and the reasonable default there is
> > dev->hotplugged = false rather than the opposite. That
> > suggests a need to fix things outside of migration.
> Agreed to a degree, i.e.
>
>    -device/device_add before machine has been started
> without migration should follow coldplug path
>
> it shouldn't cause problems for CPU/mem hotplug on x86
> and maybe will work for PCI (it may change behavior of
> ACPI based hotplug and bridges),
> CCing Marcel to confirm.

As long as machine_done is not triggered and the dev->hotplugged
is not set I suppose it will work for PCI.

But why allow device_add before the machine is running?
I don't see the benefits for it. I did see in the mail thread
that libvirt may build the machine using device_add, but
again, what is the gain? What you can do before the machine is running
do it at command line.

I would also not allow hot-plugging once migration is started
and delay migration until we finish all hot-plugging operations (not 
directly related to this thread).


Thanks,
Marcel


>


[...]