[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: |
Wed, 1 Apr 2015 18:31:23 +0200 |
On Wed, 1 Apr 2015 10:01:13 -0300
Eduardo Habkost <address@hidden> wrote:
> On Tue, Mar 31, 2015 at 10:09:09PM +0200, Michael Mueller wrote:
> > 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
> > query-cpu-definitions.
> > 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
> > "kvm"
> > has to contain "2827-ga2" with the attribute runnable set to true. With
> > that mechanism
> > also the largest common denominator can be calculated. That model will be
> > used then.
>
> Understood. So the point is to really have a name that can be found at
> query-cpu-definitions. Makes sense.
>
> (BTW, if you reused strdup_s390_cpu_name() inside
> s390_cpu_compare_class_name() too, you would automatically ensure that
> query-cpus, query-cpu-definitions and s390_cpu_class_by_name() will
> always agree with each other).
I have to verify but it seems to make sense from reading... I will do that if
it works. :-)
>
> >
> > 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");
> > }
> > }
>
> What about:
>
> static const char *s390_cpu_name(S390CPUClass *cc)
> {
> return cc->model_name;
> }
>
> And then you can just set cc->model_name=_name inside S390_PROC_DEF (and
> set it to "none" inside s390_cpu_class_init()).
>
Wouldn't that store redundant information... but it would at least shift the
work into the
initialization phase and do the format just once per model.
> I wonder if this class->model_name conversion could be made generic
> inside the CPU class. We already have a CPU::class_by_name() method, so
> it makes sense to have the opposite function too.
>
> (But I wouldn't mind making this s390-specific first, and converted
> later to generic code if appropriate).
ok
>
> >
> > This implicitly will fail a comparison for cpu model ("none", "kvm") as
> > that will
> > never be part of the query-cpu-definitions answer.
>
> I am not sure I follow. If ("none", "kvm") is never in the list, is
> "-cpu none -machine accel=kvm" always an invalid use case?
Not directly invalid as "-cpu none" will be the same as omitting the -cpu
option.
KVM will setup the vcpu properties withou any QEMU control to whatever the
hosting
machine and the kvm kernel code offers. That will allow to run QEMU against a
KVM
version that is not aware of the s390 cpu model ioctls.
>
> (I don't understand completely the meaning of "-cpu none" yet. How does
> the CPU look like for the guest in this case? Is it possible to
> live-migrate when using -cpu none?)
And yes, that does not make sense in a migration context. The answer on
query-cpu-model
(or query-cpus) will be ("none", "kvm") and that will never match a runnable
model.
The guest cpu will be derived from the hosting system and the kvm kernel as it
is currently
without the cpu model interface.
I hope I made it better to understand now...
Michael
>
- Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model, Eduardo Habkost, 2015/04/01
- Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model,
Michael Mueller <=
- Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model, Eduardo Habkost, 2015/04/01
- Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model, Michael Mueller, 2015/04/01
- Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model, Michael Mueller, 2015/04/01
- Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model, Eduardo Habkost, 2015/04/01
- Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model, Michael Mueller, 2015/04/02
- Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model, Eduardo Habkost, 2015/04/02