On 24/05/2017 17:54, Greg Kurz wrote: > On Wed, 24 May 2017 12:14:02 +0200 > Igor Mammedov <imamm...@redhat.com> wrote: > >> On Wed, 24 May 2017 11:28:57 +0200 >> Greg Kurz <gr...@kaod.org> wrote: >> >>> On Wed, 24 May 2017 15:07:54 +1000 >>> David Gibson <da...@gibson.dropbear.id.au> wrote: >>> >>>> On Tue, May 23, 2017 at 01:18:11PM +0200, Laurent Vivier wrote: >>>>> If the OS is not started, QEMU sends an event to the OS >>>>> that is lost and cannot be recovered. An unplug is not >>>>> able to restore QEMU in a coherent state. >>>>> So, while the OS is not started, disable CPU and memory hotplug. >>>>> We use option vector 6 to know if the OS is started >>>>> >>>>> Signed-off-by: Laurent Vivier <lviv...@redhat.com> >>>> >>>> Urgh.. I'm not terribly confident that this is really correct. As >>>> discussed on the previous patch, you're essentially using OV6 as a >>>> flag that CAS is complete. >>>> >>>> But while it undoubtedly makes the race window much smaller, I don't >>>> see that there's any guarantee the guest OS will really be able to >>>> handle hotplug events immediately after CAS. >>>> >>>> In particular if the CAS process completes partially but then needs to >>>> trigger a reboot, I think that would end up setting the ov6 variable, >>>> but the OS would definitely not be in a state to accept events. >> wouldn't guest on reboot pick up updated fdt and online hotplugged >> before crash cpu along with initial cpus? >> > > Yes and that's what actually happens with cpus. > > But catching up with the background for this series, I have the > impression that the issue isn't the fact we loose an event if the OS > isn't started (which is not true), but more something wrong happening > when hotplugging+unplugging memory as described in this commit: > > commit fe6824d12642b005c69123ecf8631f9b13553f8b > Author: Laurent Vivier <lviv...@redhat.com> > Date: Tue Mar 28 14:09:34 2017 +0200 > > spapr: fix memory hot-unplugging >
Yes, this commit try to fix that, but it's not possible. Some objects remain in memory: you can see with "info cpus" or "info memory-devices" that they are not really removed, and this prevents to hotplug them again, and moreover in the case of the memory hot-unplug we can rerun the device_del and crash qemu (as before the fix). Moreover all stuff normally cleared in detach() are not, and we can't do it later in set_allocation_state() because some are in use by the kernel, and this is the last call from the kernel. Laurent