All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Bharata B Rao <bharata@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, qemu-ppc@nongnu.org, groug@kaod.org,
	nikunj@linux.vnet.ibm.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH v2 2/5] cpu: Introduce CPUState::stable_cpu_id
Date: Mon, 11 Jul 2016 13:22:37 +1000	[thread overview]
Message-ID: <20160711032237.GJ16355@voom.fritz.box> (raw)
In-Reply-To: <20160708131102.73f7e998@nial.brq.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4851 bytes --]

On Fri, Jul 08, 2016 at 01:11:02PM +0200, Igor Mammedov wrote:
> On Fri, 8 Jul 2016 15:19:58 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Thu, Jul 07, 2016 at 08:20:22PM +0530, Bharata B Rao wrote:
> > > Add CPUState::stable_cpu_id and use that as instance_id in
> > > vmstate_register() call.
> > > 
> > > Introduce has-stable_cpu_id property that allows target machines to
> > > optionally switch to using stable_cpu_id instead of cpu_index.
> > > This will help allow successful migration in cases where holes are
> > > introduced in cpu_index range after CPU hot removals.
> > > 
> > > Suggested-by: Igor Mammedov <imammedo@redhat.com>
> > > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > > ---
> > >  exec.c            | 6 ++++--
> > >  include/qom/cpu.h | 5 +++++
> > >  qom/cpu.c         | 6 ++++++
> > >  3 files changed, 15 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/exec.c b/exec.c
> > > index fb73910..3b36fe5 100644
> > > --- a/exec.c
> > > +++ b/exec.c
> > > @@ -619,12 +619,14 @@ static void cpu_release_index(CPUState *cpu)
> > >  void cpu_vmstate_register(CPUState *cpu)
> > >  {
> > >      CPUClass *cc = CPU_GET_CLASS(cpu);
> > > +    int instance_id = cpu->has_stable_cpu_id ? cpu->stable_cpu_id :
> > > +                      cpu->cpu_index;
> > >  
> > >      if (qdev_get_vmsd(DEVICE(cpu)) == NULL) {
> > > -        vmstate_register(NULL, cpu->cpu_index, &vmstate_cpu_common, cpu);
> > > +        vmstate_register(NULL, instance_id, &vmstate_cpu_common, cpu);
> > >      }
> > >      if (cc->vmsd != NULL) {
> > > -        vmstate_register(NULL, cpu->cpu_index, cc->vmsd, cpu);
> > > +        vmstate_register(NULL, instance_id, cc->vmsd, cpu);
> > >      }
> > >  }
> > >  
> > > diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> > > index 331386f..527c021 100644
> > > --- a/include/qom/cpu.h
> > > +++ b/include/qom/cpu.h
> > > @@ -273,6 +273,9 @@ struct qemu_work_item {
> > >   * @kvm_fd: vCPU file descriptor for KVM.
> > >   * @work_mutex: Lock to prevent multiple access to queued_work_*.
> > >   * @queued_work_first: First asynchronous work pending.
> > > + * @stable_cpu_id: Use as instance_id argument in cpu vmstate_register calls
> > > + * @has_stable_cpu_id: Set to enforce the use of @stable_cpu_id
> > > + *     over cpu_index during vmstate registration.
> > >   *
> > >   * State of one CPU core or thread.
> > >   */
> > > @@ -360,6 +363,8 @@ struct CPUState {
> > >         (absolute value) offset as small as possible.  This reduces code
> > >         size, especially for hosts without large memory offsets.  */
> > >      uint32_t tcg_exit_req;
> > > +    int stable_cpu_id;
> > > +    bool has_stable_cpu_id;
> > >  };
> > >  
> > >  QTAILQ_HEAD(CPUTailQ, CPUState);
> > > diff --git a/qom/cpu.c b/qom/cpu.c
> > > index 1095ea1..bae1bf7 100644
> > > --- a/qom/cpu.c
> > > +++ b/qom/cpu.c
> > > @@ -363,6 +363,11 @@ static int64_t cpu_common_get_arch_id(CPUState *cpu)
> > >      return cpu->cpu_index;
> > >  }
> > >  
> > > +static Property cpu_common_properties[] = {
> > > +    DEFINE_PROP_BOOL("has-stable-cpu-id", CPUState, has_stable_cpu_id, false),  
> > 
> > It seems odd to me that stable_cpu_id itself isn't exposed as a
> > property.  Even if we don't need to set it externally for now, it
> > really should be QOM introspectable.
> Should it? Why?

Well, for one thing it's really strange to have the boolean flag
exposed, but not the value itself.

> It's QEMU internal detail and outside world preferably shouldn't
> know anything about it.

Hrm.. I guess kinda.  But I think it's less an internal detail than
the existing cpu_index is.

> As example look at cpu_index which were/is used in HMP and -numa
> interfaces and now mgmt tries make some sense of it.
> 
> Cleaner way should be teaching -numa to handle cpus specified by
> socket/core/thread IDs so that mgmt would actually know what CPUs
> it assigns to what nodes and not to look at/invent/generate some
> internal cpu_id.
> 
> > 
> > > +    DEFINE_PROP_END_OF_LIST()
> > > +};
> > > +
> > >  static void cpu_class_init(ObjectClass *klass, void *data)
> > >  {
> > >      DeviceClass *dc = DEVICE_CLASS(klass);
> > > @@ -394,6 +399,7 @@ static void cpu_class_init(ObjectClass *klass, void *data)
> > >       * IRQs, adding reset handlers, halting non-first CPUs, ...
> > >       */
> > >      dc->cannot_instantiate_with_device_add_yet = true;
> > > +    dc->props = cpu_common_properties;
> > >  }
> > >  
> > >  static const TypeInfo cpu_type_info = {  
> > 
> 

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-07-11  3:22 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-07 14:50 [Qemu-devel] [RFC PATCH v2 0/5] sPAPR: Fix migration when CPUs are removed in random order Bharata B Rao
2016-07-07 14:50 ` [Qemu-devel] [RFC PATCH v2 1/5] cpu, target-ppc: Move cpu_vmstate_[un]register calls to cpu_common_[un]realize Bharata B Rao
2016-07-07 14:50 ` [Qemu-devel] [RFC PATCH v2 2/5] cpu: Introduce CPUState::stable_cpu_id Bharata B Rao
2016-07-07 17:52   ` Greg Kurz
2016-07-08  5:21     ` David Gibson
2016-07-08  5:19   ` David Gibson
2016-07-08 11:11     ` Igor Mammedov
2016-07-11  3:22       ` David Gibson [this message]
2016-07-11  3:35         ` Bharata B Rao
2016-07-11  7:42           ` Igor Mammedov
2016-07-11 13:42           ` [Qemu-devel] [PATCH] VARIANT 1: reuse device compat logic to pick preffered CPU's migration instance_id Igor Mammedov
2016-07-11 13:42             ` [Qemu-devel] [PATCH] VARIANT 2: use machine specific callback to pick " Igor Mammedov
2016-07-11 14:15             ` [Qemu-devel] [PATCH] VARIANT 1: reuse device compat logic to pick preffered " Paolo Bonzini
2016-07-12  5:07             ` David Gibson
2016-07-12  8:11               ` Igor Mammedov
2016-07-13  1:39                 ` David Gibson
2016-07-12  7:06             ` Bharata B Rao
2016-07-12  8:21               ` Igor Mammedov
2016-07-12 11:08               ` [Qemu-devel] [PATCH v2 1/2] cpu: add migration_id to allow board to provide " Igor Mammedov
2016-07-12 11:08                 ` [Qemu-devel] [PATCH v2 2/2] pc: fix migration failure after cpu hot-unplung Igor Mammedov
2016-07-11  7:58         ` [Qemu-devel] [RFC PATCH v2 2/5] cpu: Introduce CPUState::stable_cpu_id Igor Mammedov
2016-07-12  5:09           ` David Gibson
2016-07-07 14:50 ` [Qemu-devel] [RFC PATCH v2 3/5] spapr: Set stable_cpu_id for threads of CPU cores Bharata B Rao
2016-07-07 16:11   ` Greg Kurz
2016-07-08  5:25     ` David Gibson
2016-07-08  7:46       ` Greg Kurz
2016-07-08  7:59         ` David Gibson
2016-07-08 15:24           ` Greg Kurz
2016-07-11  3:23             ` David Gibson
2016-07-08  5:24   ` David Gibson
2016-07-08  6:41     ` Bharata B Rao
2016-07-08  7:39       ` David Gibson
2016-07-08 10:59         ` Igor Mammedov
2016-07-11  3:12           ` Bharata B Rao
2016-07-11  3:26           ` David Gibson
2016-07-11  8:15             ` Igor Mammedov
2016-07-12  4:41               ` David Gibson
2016-07-07 14:50 ` [Qemu-devel] [RFC PATCH v2 4/5] xics: Use stable_cpu_id instead of cpu_index in XICS code Bharata B Rao
2016-07-08  5:32   ` David Gibson
2016-07-07 14:50 ` [Qemu-devel] [RFC PATCH v2 5/5] spapr: Enable the use of stable_cpu_id from pseries-2.7 onwards Bharata B Rao
2016-07-07 16:04 ` [Qemu-devel] [RFC PATCH v2 0/5] sPAPR: Fix migration when CPUs are removed in random order Greg Kurz
2016-07-08  5:34   ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160711032237.GJ16355@voom.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=groug@kaod.org \
    --cc=imammedo@redhat.com \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.