On Thu, Jul 21, 2016 at 05:54:37PM +0200, Igor Mammedov wrote: > It will enshure that cpu_index for a given cpu stays the same > regardless of the order cpus has been created/deleted and so > it would be possible to migrate QEMU instance with out of order > created CPU. > > Signed-off-by: Igor Mammedov <imamm...@redhat.com>
So, this isn't quite right (it wasn't right in my version either).
The problem occurs when smp_threads < kvmppc_smt_threads(). That is,
when the requested threads-per-core is less than the hardware's
maximum number of threads-per-core.
The core-id values are assigned essentially as i *
kvmppc_smt_threads(), meaning the patch below will leave gaps in the
cpu_index values and the last ones will exceed max_cpus, causing other
problems.
What I'm not sure about is whether the right way to fix this is to
change the core-id values, or to calculate the cpu_index from the
existing core-id values.
> ---
> hw/ppc/spapr_cpu_core.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index 4bfc96b..f68e88d 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -309,9 +309,13 @@ static void spapr_cpu_core_realize(DeviceState *dev,
> Error **errp)
> sc->threads = g_malloc0(size * cc->nr_threads);
> for (i = 0; i < cc->nr_threads; i++) {
> char id[32];
> + CPUState *cs;
> +
> obj = sc->threads + i * size;
>
> object_initialize(obj, size, typename);
> + cs = CPU(obj);
> + cs->cpu_index = cc->core_id + i;
> snprintf(id, sizeof(id), "thread[%d]", i);
> object_property_add_child(OBJECT(sc), id, obj, &local_err);
> if (local_err) {
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
