qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 0/4] prebuild cpu QOM tree /machine/node/sock


From: Chen Fan
Subject: Re: [Qemu-devel] [PATCH v1 0/4] prebuild cpu QOM tree /machine/node/socket/core ->link-cpu
Date: Thu, 20 Mar 2014 08:55:08 +0800

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]