Ah! So it's broken for the prelaunch case as well, though in a
slightly different way. Actually for me the breakage is less obvious
- if I plug the cpu at prelaunch, I *do* get 2 cpus appearing in the
running system. But tracing through, that's because the hotplug
message was queued and gets processed during boot. That gets to the
right place in the end, but it's kind of silly going through the
hotplug logic.
I thought there was a system reset after the prelaunch phase, but I
was mistaken.
I can see two ways to address this:
1) add in a DRC reset before starting up the machine, for both the
prelaunch and inmigrate cases. Your draft patch does the second,
but I don't see an obvious place to put a hook for the first
2) Change the plug (and unplug) paths to skip the notification and
gradual state change, and just immediately jump to the completed
state when called in the prelaunch or inmigrate. (Easiest way
would be just to call the drc reset function instead of queueing
an event).
(2) is basically the approach Laurent proposed in a patch a little
while ago, defining an spapr_hotplugged() function that always
returned false in prelaunch or inmigrate states.
At the time I was dubious about that approach, because I thought we
had a natural reset point after that. After more careful
investigation, I think that's not the case however, so I'm inclined to
go with approach (2), polish up Laurent's patch and apply that.
Agreed. I remember Laurent's patch and I think it covers both
scenarios in a better