On Mon, May 18, 2015 at 04:09:49PM -0300, Eduardo Habkost wrote: > On Tue, May 12, 2015 at 11:06:23AM +0530, Bharata B Rao wrote: > > This patch changes the way cpu_index is handed out to newly created > > CPUs by tracking the allocted CPUs in a bitmap. More information and > > the need for this patch is described in patch 2/3 of this series. These > > generic changes are needed to support CPU hot plug/unplug on PowerPC. > > What about the existing vmstate and savevm calls on cpu_exec_init()? > Won't QEMU crash if you destroy the CPU without unregistering the > vmstate and savevm handlers?
There was a patch from Zhu to move the vmstate registration code into cpu_common_realizefn http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01550.html Also there was also a patch to do unregistration from target CPU's unrealizefn for x86. https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg02599.html On PowerPC Currently I do unregistration in the ppc CPU's unrealizefn. But irrespective of how the above patches evolve, does it make sense to have unregistration part done in cpu_exec_exit() now as part of this patch series ? > > > > > An open question is about handling of holes correctly in the allocated > > bitmap to support VM migration after CPU unplug. This was briefly discussed > > here: > > > > https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg00560.html > > > > Should cpu_exec_init() API support specifying of a particular cpu_index > > in addition to returning the next available cpu_index by default ? I know > > that QEMU cmdline semantics for CPU device add/delele haven't been defined > > yet, but should we now make provision in cpu_exec_init() to allocate the > > required cpu_index ? > > I don't believe we need it, and instead we should make cpu_index > irrelevant. cpu_index is just an arbitrary ID assigned to the CPU, and > any interface that depends on it for something needs to use clearer and > more meaningful parameters as input (such as socket/core/thread > information), instead of cpu_index. > > For example, on X86 the APIC ID depends on the CPU socket/core/thread > IDs, and today we just use the cpu_index to calculate it. In the future, > we need to let users choose (directly or indirectly) the specific > socket/core/thread IDs for the CPU, so the APIC ID can be calculated > without requiring cpu_index. > > Probably the same applies to cpu_dt_id on PPC: you need to be able to > calculate cpu_dt_id without cpu_index (using core and thread IDs as > input, I guess?). I see your point and need more thinking to see how to disassociate cpu_dt_id from cpu_index on PowerPC. Regards, Bharata.
