| Message ID | 70d79d019b2032cec129693162d0d51ef7d9775e.1394609102.git.chen.fan.fnst@cn.fujitsu.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Mar 12, 2014 at 03:51:34PM +0800, Chen Fan wrote: > Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com> > --- > target-i386/topology.h | 33 +++++++++++++++++---------------- > 1 file changed, 17 insertions(+), 16 deletions(-) > > diff --git a/target-i386/topology.h b/target-i386/topology.h > index 07a6c5f..9b811c1 100644 > --- a/target-i386/topology.h > +++ b/target-i386/topology.h > @@ -47,6 +47,12 @@ > */ > typedef uint32_t apic_id_t; > > +typedef struct X86CPUTopoInfo { > + unsigned pkg_id; > + unsigned core_id; > + unsigned smt_id; > +} X86CPUTopoInfo; > + > /* Return the bit width needed for 'count' IDs > */ > static unsigned apicid_bitwidth_for_count(unsigned count) > @@ -92,13 +98,11 @@ static inline unsigned apicid_pkg_offset(unsigned nr_cores, unsigned nr_threads) > */ > static inline apic_id_t apicid_from_topo_ids(unsigned nr_cores, > unsigned nr_threads, > - unsigned pkg_id, > - unsigned core_id, > - unsigned smt_id) > + X86CPUTopoInfo *topo) topo could be const X86CPUTopoInfo*, but not a big deal. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
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. :) Chen Fan (4): cpu: introduce CpuTopoInfo structure for argument simplification i386: use CpuTopoInfo instead apic_id as argument for pc_new_cpu() topo unit-test: update Unit tests to test-x86-cpuid.c i386: introduce cpu QOM hierarchy tree hw/i386/pc.c | 25 +++--- target-i386/Makefile.objs | 2 +- target-i386/cpu-topology.c | 199 +++++++++++++++++++++++++++++++++++++++++++++ target-i386/cpu-topology.h | 71 ++++++++++++++++ target-i386/cpu.c | 55 +++++++++---- target-i386/cpu.h | 8 ++ target-i386/topology.h | 53 +++++++----- tests/test-x86-cpuid.c | 165 +++++++++++++++++++++++++++++-------- 8 files changed, 494 insertions(+), 84 deletions(-) create mode 100644 target-i386/cpu-topology.c create mode 100644 target-i386/cpu-topology.h
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.
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
diff --git a/target-i386/topology.h b/target-i386/topology.h index 07a6c5f..9b811c1 100644 --- a/target-i386/topology.h +++ b/target-i386/topology.h @@ -47,6 +47,12 @@ */ typedef uint32_t apic_id_t; +typedef struct X86CPUTopoInfo { + unsigned pkg_id; + unsigned core_id; + unsigned smt_id; +} X86CPUTopoInfo; + /* Return the bit width needed for 'count' IDs */ static unsigned apicid_bitwidth_for_count(unsigned count) @@ -92,13 +98,11 @@ static inline unsigned apicid_pkg_offset(unsigned nr_cores, unsigned nr_threads) */ static inline apic_id_t apicid_from_topo_ids(unsigned nr_cores, unsigned nr_threads, - unsigned pkg_id, - unsigned core_id, - unsigned smt_id) + X86CPUTopoInfo *topo) { - return (pkg_id << apicid_pkg_offset(nr_cores, nr_threads)) | - (core_id << apicid_core_offset(nr_cores, nr_threads)) | - smt_id; + return (topo->pkg_id << apicid_pkg_offset(nr_cores, nr_threads)) | + (topo->core_id << apicid_core_offset(nr_cores, nr_threads)) | + topo->smt_id; } /* Calculate thread/core/package IDs for a specific topology, @@ -107,14 +111,12 @@ static inline apic_id_t apicid_from_topo_ids(unsigned nr_cores, static inline void x86_topo_ids_from_idx(unsigned nr_cores, unsigned nr_threads, unsigned cpu_index, - unsigned *pkg_id, - unsigned *core_id, - unsigned *smt_id) + X86CPUTopoInfo *topo) { unsigned core_index = cpu_index / nr_threads; - *smt_id = cpu_index % nr_threads; - *core_id = core_index % nr_cores; - *pkg_id = core_index / nr_cores; + topo->smt_id = cpu_index % nr_threads; + topo->core_id = core_index % nr_cores; + topo->pkg_id = core_index / nr_cores; } /* Make APIC ID for the CPU 'cpu_index' @@ -125,10 +127,9 @@ static inline apic_id_t x86_apicid_from_cpu_idx(unsigned nr_cores, unsigned nr_threads, unsigned cpu_index) { - unsigned pkg_id, core_id, smt_id; - x86_topo_ids_from_idx(nr_cores, nr_threads, cpu_index, - &pkg_id, &core_id, &smt_id); - return apicid_from_topo_ids(nr_cores, nr_threads, pkg_id, core_id, smt_id); + X86CPUTopoInfo topo; + x86_topo_ids_from_idx(nr_cores, nr_threads, cpu_index, &topo); + return apicid_from_topo_ids(nr_cores, nr_threads, &topo); } #endif /* TARGET_I386_TOPOLOGY_H */
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com> --- target-i386/topology.h | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-)