From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55738)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <chen.fan.fnst@cn.fujitsu.com>) id 1WQRZx-0003bb-W0
	for qemu-devel@nongnu.org; Wed, 19 Mar 2014 21:15:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <chen.fan.fnst@cn.fujitsu.com>) id 1WQRZr-0002Vq-Pl
	for qemu-devel@nongnu.org; Wed, 19 Mar 2014 21:15:29 -0400
Received: from [222.73.24.84] (port=11937 helo=song.cn.fujitsu.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <chen.fan.fnst@cn.fujitsu.com>) id 1WQRZr-0002VF-D1
	for qemu-devel@nongnu.org; Wed, 19 Mar 2014 21:15:23 -0400
Message-ID: <1395276908.12213.0.camel@G08FNSTD131468>
From: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Date: Thu, 20 Mar 2014 08:55:08 +0800
In-Reply-To: <532986C3.6000607@redhat.com>
References: <20140312153631.GE29225@otherpad.lan.raisama.net>
	<cover.1395217538.git.chen.fan.fnst@cn.fujitsu.com>
	<532986C3.6000607@redhat.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [Qemu-devel] [PATCH v1 0/4] prebuild cpu QOM tree
 /machine/node/socket/core ->link-cpu
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eric Blake <eblake@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>, Eduardo Habkost <ehabkost@redhat.com>, Andreas =?ISO-8859-1?Q?F=E4rber?= <afaerber@suse.de>, qemu-devel@nongnu.org

On Wed, 2014-03-19 at 06:00 -0600, Eric Blake wrote:
> On 03/19/2014 02:53 AM, Chen Fan wrote:
> > at present, after hotplug a discontinuous cpu id on source, then done migration,
> > on target, it will fail to add the unoccupied cpu id which was skipped at source,
> > this cause is on target Qemu prebuild CPU with continuous cpu_index. so after
> > migration, the cpu infrastructure bewteen source and target are different.
> >  
> > I suppose we could use apic_id as instance_id which was used at registering vmstate
> > when create cpu. on target, we prebuild the specified cpu topology using comand line:
> >   -device /machine/node[]/socket[]/core[]/cpu[], then migration, we could keep the same
> > cpu infrastructure on both side.
> > 
> > RFC:
> >  V4: rename CpuTopoInfo to X86CPUTopoInfo. and move cpu_exsit() to pc_new_cpu().
> > 
> >  V3: get rid of thread object and tie link<cpu> to <core> directly. and prebuild full
> >   core[] and thread[] as init socket[] according to smp_cores and smp_threads.
> > 
> >  TODO:
> >   1. add cpu "path" property which used for specifying the QOM path.
> >   2. add -device cpu-foo.path supported.
> >   3. then we could introduce hot-remove cpu probably.
> > 
> >  I don't know wether this way is right or not. pls tell me. :)
> 
> When sending a cover letter for a new revision of a patch series, we
> generally do NOT use In-Reply-To headers, but instead send it as a new
> thread.  Patches are harder to see when they are buried as a reply to
> another thread.
> 
I see, Thanks.

Chen