Re: [Qemu-devel] [PATCH v2 0/3] Bitmap based CPU enumeration

[Bharata B Rao]

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.