On 27/03/2019 17:52, Juergen Gross wrote: > On 27/03/2019 17:38, Jan Beulich wrote: >>>>> On 27.03.19 at 17:18, <jgr...@suse.com> wrote: >>> On 27/03/2019 16:55, Andrew Cooper wrote: >>>> On 18/03/2019 13:11, Juergen Gross wrote: >>>>> Instead of freeing percpu areas during suspend and allocating them >>>>> again when resuming keep them. Only free an area in case a cpu didn't >>>>> come up again when resuming. >>>>> >>>>> Signed-off-by: Juergen Gross <jgr...@suse.com> >>>> >>>> Hmm - this is slightly problematic, given the dual nature of this code. >>>> >>>> I agree that it this change is beneficial for the suspend case, but it >>>> is a problem when we are parking an individual CPU for smt=0 or >>>> xen-hptool reasons. >>>> >>>> Do we have any hint we can use when taking the CPU down as to whether >>>> we're expecting it to come straight back up again? >>> >>> Did you look into the patch? I did this by testing system_state. >> >> I think there's a wider problem here: enable_nonboot_cpus() >> only brings back up the CPUs that were previously online. >> Parked ones would be left alone, yet after resume they'd >> need to be put back into parked state. > > I can add that handling in the respin of the series.
Looking deeper into that mess I believe that should be a series of its own. Cpu parking needs to be handled for cpu hotplug and core parking (XENPF_core_parking), too. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
