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.