Re: [Qemu-devel] [RFC PATCH v0 1/1] spapr: Support setting of compat CPU type for CPU cores

[Bharata B Rao <bharata@linux.vnet.ibm.com>]

On Tue, Jun 21, 2016 at 08:04:12AM +0200, Thomas Huth wrote:
> On 18.06.2016 10:34, Bharata B Rao wrote:
> > Compat CPU type is typically specified on -cpu cmdline option like:
> > -cpu host,compat=power7 or -cpu POWER8E,compat=power7 etc.
> > With the introduction of sPAPR CPU core devices, we need to support
> > the same for core devices too.
> > 
> > Support the specification of CPU compat type on device_add command for
> > sPAPRCPUCore devices like:
> > (qemu) device_add POWER8E-spapr-cpu-core,id=core3,compat=power7,core-id=24
> >
> > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > ---
> > Applies on ppc-for-2.7 branch of David Gibson's tree.
> > 
> >  hw/ppc/spapr.c                  |  8 +++++
> >  hw/ppc/spapr_cpu_core.c         | 73 +++++++++++++++++++++++++++++++++++++++++
> >  include/hw/ppc/spapr_cpu_core.h |  2 ++
> >  3 files changed, 83 insertions(+)
> [...]
> > diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> > index 3a5da09..9eb63cc 100644
> > --- a/hw/ppc/spapr_cpu_core.c
> > +++ b/hw/ppc/spapr_cpu_core.c
> > @@ -96,6 +96,24 @@ char *spapr_get_cpu_core_type(const char *model)
> >      return core_type;
> >  }
> >  
> > +/*
> > + * Returns the CPU compat type specified in -cpu @model.
> > + */
> > +char *spapr_get_cpu_compat_type(const char *model)
> > +{
> > +    char *compat_type = NULL;
> > +    gchar **model_pieces = g_strsplit(model, ",", 2);
> > +
> > +    if (model_pieces[1]) {
> > +        gchar **compat_pieces = g_strsplit(model_pieces[1], "=", 2);
> > +
> > +        compat_type = g_strdup_printf("%s", compat_pieces[1]);
> > +    }
> > +
> > +    g_strfreev(model_pieces);
> > +    return compat_type;
> > +}
> 
> Shouldn't you check for "compat=" somewhere in this function (and
> properly iterate over all parts of the comma separated string)? In case
> we support more properties than "compat=" some day, this will go wrong
> otherwise...

Currently since it is only "compat=", anything else would fail gracefully
when the property gets set. But obviously that is not future-safe as you
note. Let me rework on this.

Regards,
Bharata