From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37530) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYWeS-0003n4-C7 for qemu-devel@nongnu.org; Mon, 29 Sep 2014 04:49:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XYWeM-0004qy-7b for qemu-devel@nongnu.org; Mon, 29 Sep 2014 04:49:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYWeL-0004q1-WF for qemu-devel@nongnu.org; Mon, 29 Sep 2014 04:49:42 -0400 Date: Mon, 29 Sep 2014 10:49:44 +0200 From: Igor Mammedov Message-ID: <20140929104944.64a041e5@igors-macbook-pro.local> In-Reply-To: <20140929030015.GA21207@in.ibm.com> References: <1409810785-12391-1-git-send-email-bharata@linux.vnet.ibm.com> <1409810785-12391-11-git-send-email-bharata@linux.vnet.ibm.com> <20140926172902.3b0bdf4a@nial.usersys.redhat.com> <20140929030015.GA21207@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v0 10/15] ppc: Factor out CPU initialization code to a new routine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com On Mon, 29 Sep 2014 08:30:15 +0530 Bharata B Rao wrote: > On Fri, Sep 26, 2014 at 05:29:02PM +0200, Igor Mammedov wrote: > > On Thu, 4 Sep 2014 11:36:20 +0530 > > Bharata B Rao wrote: > > > > > Separate out CPU initialization code into a new routine > > > ppc_new_cpu() so that it can be used from CPU hotplug path too. > > > > > > Signed-off-by: Bharata B Rao > > > --- > > > hw/ppc/spapr.c | 73 > > > +++++++++++++++++++++++++++++++++------------------------- 1 file > > > changed, 42 insertions(+), 31 deletions(-) > > > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > > > index b2ca527..41207ae 100644 > > > --- a/hw/ppc/spapr.c > > > +++ b/hw/ppc/spapr.c > > > @@ -1603,6 +1603,45 @@ static SaveVMHandlers savevm_htab_handlers > > > = { .load_state = htab_load, > > > }; > > > > > looking at following code from POV of using CPU with device_add cmd. > > > > > +static const char *current_cpu_model; > > do PPC CPUs use full 'model-name,feature1,-feature2' format or only > > model-name from cpu_model string? > > I think it is just the model-name. Then without lagacy baggage that x86 has, it should be possible to convert PPC to device_add/del supported object. You wont't need a global to keep model name, it will come as type name device_add command. > > > > > > +static PowerPCCPU *ppc_new_cpu(const char *cpu_model) > > > +{ > > > + PowerPCCPU *cpu; > > > + CPUPPCState *env; > > > + > > > + cpu = cpu_ppc_init(cpu_model); for fully QOMified CPU you don't need cpu_ppc_init() object_new() should be sufficient. > > > + if (cpu == NULL) { > > > + fprintf(stderr, "Unable to find PowerPC CPU > > > definition\n"); > > > + exit(1); > > > + } > > > > -- cut -- > > > + env = &cpu->env; > > > + > > > + /* Set time-base frequency to 512 MHz */ > > > + cpu_ppc_tb_init(env, TIMEBASE_FREQ); > > > + > > > + /* PAPR always has exception vectors in RAM not ROM. To > > > ensure this, > > > + * MSR[IP] should never be set. > > > + */ > > > + env->msr_mask &= ~(1 << 6); > > > + > > > + /* Tell KVM that we're in PAPR mode */ > > > + if (kvm_enabled()) { > > > + kvmppc_set_papr(cpu); > > > + } > > > + > > > + if (cpu->max_compat) { > > > + if (ppc_set_compat(cpu, cpu->max_compat) < 0) { > > > + exit(1); > > > + } > > > + } > > -- cut -- > > selected block looks like setting CPU internals, which could be done > > inside of CPU's realizefn. > > > > > + > > > + xics_cpu_setup(spapr->icp, cpu); xics_cpu_setup() looks like a wiring of CPU with external component. I'd move it into plug handler and handle it in PPCMAchine object. It should be possible to split/move the rest of this function into initfn()/realize() of CPU. > > > > > > > + qemu_register_reset(spapr_cpu_reset, cpu); > > also could be put inside of CPU's realizefn, like it's done in > > for x86 CPU. > > Right, I just converted my CPU hotplug patchset for PowerPC to use the > hotplug handler APIs and now working on to see if I can switch over to > device_add and support device_del for CPU hotplug on PowerPC. > > Regards, > Bharata. >