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
