From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMReK-0006w0-JJ for qemu-devel@nongnu.org; Sun, 10 Jul 2016 23:12:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMReG-0001j4-Ar for qemu-devel@nongnu.org; Sun, 10 Jul 2016 23:12:47 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:59077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMReG-0001ir-2S for qemu-devel@nongnu.org; Sun, 10 Jul 2016 23:12:44 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u6B397Gj013442 for ; Sun, 10 Jul 2016 23:12:42 -0400 Received: from e28smtp09.in.ibm.com (e28smtp09.in.ibm.com [125.16.236.9]) by mx0a-001b2d01.pphosted.com with ESMTP id 242wt5afx9-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Sun, 10 Jul 2016 23:12:42 -0400 Received: from localhost by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 11 Jul 2016 08:42:39 +0530 Date: Mon, 11 Jul 2016 08:42:31 +0530 From: Bharata B Rao Reply-To: bharata@linux.vnet.ibm.com References: <1467903025-13383-1-git-send-email-bharata@linux.vnet.ibm.com> <1467903025-13383-4-git-send-email-bharata@linux.vnet.ibm.com> <20160708052413.GM14675@voom.fritz.box> <20160708064112.GK25522@in.ibm.com> <20160708073952.GQ14675@voom.fritz.box> <20160708125959.2a5c35bb@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160708125959.2a5c35bb@nial.brq.redhat.com> Message-Id: <20160711031231.GM25522@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 3/5] spapr: Set stable_cpu_id for threads of CPU cores List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: David Gibson , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, groug@kaod.org, nikunj@linux.vnet.ibm.com, pbonzini@redhat.com On Fri, Jul 08, 2016 at 12:59:59PM +0200, Igor Mammedov wrote: > On Fri, 8 Jul 2016 17:39:52 +1000 > David Gibson wrote: > > > On Fri, Jul 08, 2016 at 12:11:12PM +0530, Bharata B Rao wrote: > > > On Fri, Jul 08, 2016 at 03:24:13PM +1000, David Gibson wrote: > > > > On Thu, Jul 07, 2016 at 08:20:23PM +0530, Bharata B Rao wrote: > > > > > Conditonally set stable_cpu_id for CPU threads that are created as part > > > > > of spapr CPU cores. The use of stable_cpu_id is enabled for pseries-2.7 > > > > > onwards. > > > > > > > > > > Signed-off-by: Bharata B Rao > > > > > --- > > > > > hw/ppc/spapr_cpu_core.c | 7 +++++++ > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c > > > > > index b104778..0ec3513 100644 > > > > > --- a/hw/ppc/spapr_cpu_core.c > > > > > +++ b/hw/ppc/spapr_cpu_core.c > > > > > @@ -293,8 +293,15 @@ static void spapr_cpu_core_realize(DeviceState *dev, Error **errp) > > > > > for (i = 0; i < cc->nr_threads; i++) { > > > > > char id[32]; > > > > > obj = sc->threads + i * size; > > > > > + CPUState *cs; > > > > > > > > > > object_initialize(obj, size, typename); > > > > > + cs = CPU(obj); > > > > > + > > > > > + /* Use core_id (which is actually cpu_dt_id) as stable CPU id */ > > > > > + if (cs->has_stable_cpu_id) { > > > > > + cs->stable_cpu_id = cc->core_id + i; > > > > > + } > > > > > > > > Testing cs->has_stable_cpu_id here in machine type specific code seems > > > > really weird. It's the machine type that knows whether it has a > > > > stable ID to give to the CPU or not, rather than the other way around. > > > > > > > > Since we haven't yet had a release with cpu cores, I think the right > > > > thing is for cpu_core to unconditionally set the stable ID (and set > > > > has_stable_id to true). > > > > > > Right, we can set cpu_stable_id unconditionally here since this code path > > > (core realize) will be taken only for pseries-2.7 onwards. has_stable_id > > > will get set as part of the property we defined in SPAPR_COMPAT_2_7. > > > > Hrm, that's true. But when you describe it like that it sounds like a > > really non-obvious and fragile dependency between different components. > that's how compat stuff is typically done for devices, > CPUs shouldn't be an exception. > (consistency with other devices helps here in long run) > > > > > The backup path that does thread-based cpu > > > > init, can set has_stable_id to false (if that's not the default). > > > > > > Default is off, but turning it on for 2.7 will be inherited by 2.6 > > > and others below. Hence I have code to explicitly disable this prop > > > for 2.6 and below via SPAPR_COMPAT_2_6. > > > > This is all seeming terribly awkward. > Typically default is set the way so new machine type doesn't have > to enable it explicitly. > > However the way it's done here helps not to touch/check every user > that uses cpu_index, limiting series impact only to code that > asks for it, it look a lot safer to got this rout for now. David, - I believe there's a consensus on using core-id as the stable_cpu_id. - You weren't liking the use of a separate property user-stable-cpu-id to control/enable the use of stable_cpu_id. After Igor's reply above, should we stick with that approach ? - I am planning to drop the code that introduces cpu_common_unrealize() and that moves vmstate_[un]register() calls to qom/cpu.c as that affects all other archs. Instead lets just check for use_stable_cpu_id from exec.c itself and use it appropriately. If you are ok with all the above, I shall post the next version on top of Greg's patchset. Regards, Bharata.