[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cp

From: Michael Mueller
Subject: Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
Date: Tue, 31 Mar 2015 22:09:09 +0200

On Tue, 31 Mar 2015 15:35:26 -0300
Eduardo Habkost <address@hidden> wrote:

> On Mon, Mar 30, 2015 at 04:28:24PM +0200, Michael Mueller wrote:
> > This patch implements a new QMP request named 'query-cpu-model'.
> > It returns the cpu model of cpu 0 and its backing accelerator.
> > 
> > request:
> >   {"execute" : "query-cpu-model" }
> > 
> > answer:
> >   {"return" : {"name": "2827-ga2", "accel": "kvm" }}
> > 
> > Alias names are resolved to their respective machine type and GA names
> > already during cpu instantiation. Thus, also a cpu model like 'host'
> > which is implemented as alias will return its normalized cpu model name.
> > 
> > Furthermore the patch implements the following function:
> > 
> > - s390_cpu_models_used(), returns true if S390 cpu models are in use
> > 
> > Signed-off-by: Michael Mueller <address@hidden>
> > ---
> [...]
> > +static inline char *strdup_s390_cpu_name(S390CPUClass *cc)
> > +{
> > +    return g_strdup_printf("%04x-ga%u", cc->proc.type, cc->mach.ga);
> > +}
> How exactly is this information going to be used by clients? If getting
> the correct type and ga values is important for them, maybe you could
> add them as integer fields, instead of requiring clients to parse the
> CPU model name?

The consumer don't need to parse the name, it is just important for them to have
distinctive names that correlate with the names returned by 
Once the name of an active guest is known, e.g. ("2827-ga2", "kvm") a potential
migration target can be verified, i.e. its query-cpu-definitions answer for 
has to contain "2827-ga2" with the attribute runnable set to true. With that 
also the largest common denominator can be calculated. That model will be used 

I also changed the above mentioned routine to map the cpu model none case:

static inline char *strdup_s390_cpu_name(S390CPUClass *cc)
    if (cpuid(cc->proc)) {
        return g_strdup_printf("%04x-ga%u", cc->proc.type, cc->mach.ga);
    } else {
        return g_strdup("none");

This implicitly will fail a comparison for cpu model ("none", "kvm") as that 
never be part of the query-cpu-definitions answer.

I actually applied a couple of your suggestions like:

- test for NULL skipped after strdup_s390_cpu_name()
- strdup_s390_cpu_name() now also handles none cpu model case
- omit runnable and is-default field from query-cpu-definitions
  answer when they are false
- global variable cpu_models_used dropped
- function s390_cpu_models_used() dropped
- routine query-cpu-definitions has a single code path now

Only the integration of the ACCEL_ID with the cpu state in cpu_generic_init() 
the change for the query-cpus implementation is under construction. I hope to 
the patches by tomorrow evening.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]