From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YuZtE-0004JC-7j for qemu-devel@nongnu.org; Tue, 19 May 2015 01:16:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YuZtA-0004sz-1Q for qemu-devel@nongnu.org; Tue, 19 May 2015 01:16:28 -0400 Received: from e28smtp09.in.ibm.com ([122.248.162.9]:54864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YuZt9-0004sA-9q for qemu-devel@nongnu.org; Tue, 19 May 2015 01:16:23 -0400 Received: from /spool/local by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 19 May 2015 10:46:19 +0530 Received: from d28relay04.in.ibm.com (d28relay04.in.ibm.com [9.184.220.61]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id 283CF1258053 for ; Tue, 19 May 2015 10:48:32 +0530 (IST) Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay04.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t4J5G5fQ2752896 for ; Tue, 19 May 2015 10:46:06 +0530 Received: from d28av05.in.ibm.com (localhost [127.0.0.1]) by d28av05.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t4J5G4EZ015668 for ; Tue, 19 May 2015 10:46:05 +0530 Date: Tue, 19 May 2015 10:46:03 +0530 From: Bharata B Rao Message-ID: <20150519051603.GA31025@in.ibm.com> References: <1431408986-18323-1-git-send-email-bharata@linux.vnet.ibm.com> <20150518190949.GE17796@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150518190949.GE17796@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] [PATCH v2 0/3] Bitmap based CPU enumeration Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: zhugh.fnst@cn.fujitsu.com, agraf@suse.de, qemu-devel@nongnu.org, imammedo@redhat.com, afaerber@suse.de, david@gibson.dropbear.id.au 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.