[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v1 RFC 6/6] KVM: s390: add cpu model support

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v1 RFC 6/6] KVM: s390: add cpu model support
Date: Tue, 20 May 2014 12:10:23 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 20.05.14 12:02, Michael Mueller wrote:
On Mon, 19 May 2014 22:14:00 +0200
Alexander Graf <address@hidden> wrote:

On 19.05.14 19:03, Michael Mueller wrote:
On Mon, 19 May 2014 16:49:28 +0200
Alexander Graf <address@hidden> wrote:


What user and thus also user space wants depends on other factors:

1. reliability
2. performance
3. availability

It's not features, that's what programmers want.

That's why I have designed the model and migration capability around the 
and not around the software features and don't allow them to be enabled 

A software feature is a nice add on that is helpful for evaluation or 
purpose. There is few space for it on productions systems.

One option that I currently see to make software implemented facility migration
capable is to calculate some kind of hash value derived from the full set of
active software facilities. That value can be compared with pre-calculated
values also stored in the supported model table of qemu. This value could be
seen like a virtual model extension that has to match like the model name.

But I have said it elsewhere already, a soft facility should be an exception and
not the rule.

So all we need is a list of "features the guest sees available" which is
the same as "features user space wants the guest to see" which then gets
masked through "features the host can do in hardware".

For emulation we can just check on the global feature availability on
whether we should emulate them or not.

Also, if user space wants to make sure that its feature list is actually
workable on the host kernel, it needs to set and get the features again
and then compare that with the ones it set? That's different from x86's
cpuid implementation but probably workable.
User space will probe what facilities are available and match them with the 
cpu model set. Only those models which use a partial or full subset of the 
facility list are selectable.
If a host does not offer the features required for a model it is not able to
run efficiently.

Please take a look at how x86 does cpuid masking :).

In fact, I'm not 100% convinced that it's a good idea to link cpuid /
feature list exposure to the guest and actual feature implementation
inside the guest together. On POWER there is a patch set pending that
implements these two things separately - admittedly mostly because
hardware sucks and we can't change the PVR.
That is maybe the big difference with s390. The cpuid in the S390 case is not
directly comparable with the processor version register of POWER.

In the S390 world we have a well defined CPU model room spanned by the machine
type and its GA count. Thus we can define a bijective mapping between
(type, ga) <-> (cpuid, ibc, facility set). From type and ga we form the model
name which BTW is meaningful also for a human user.
Same thing as POWER.

By means of this name, a management interface (libvirt) will draw decisions if
migration to a remote hypervisor is a good idea or not. For that it just needs
to compare if the current model of the guest on the source hypervisor
("query-cpu-model"), is contained in the supported model list of the target
hypervisor ("query-cpu-definitions").
I don't think this works, since QEMU should always return all the cpu
definitions it's aware of on query-cpu-definitions, not just the ones
that it thinks may be compatible with the host at a random point in time.
It does not return model names that it thinks they are compatible at some point
in time. In s390 mode, it returns all definitions (CPU models) that a given host
system is capable to run. Together with the CPU model run by the guest, some 
management interface knows if the hypervisor supports the required CPU model and
uses a guest definition with the same CPU model on the target hypervisor.

The information for that is taken from the model table which QEMU builds up 
startup time. This list limits the command line selectable CPU models as well.
This makes s390 derive from the way x86 handles things. NAK.
One second, that goes a little fast here :-). x86 returns a list they support 
which happens to
be the full list they define and s390 does logically the same because we know 
that certain
models are not supported due to probing. BTW that happens only if you run Qemu 
on back
level hardware and that is perfectly correct.
It's not what other architectures do and I'd hate to see s390 deviate
just because.
Only these four architectures implement the query and they all differ a 

target-arm/helper.c:CpuDefinitionInfoList *arch_query_cpu_definitions(Error 
target-i386/cpu.c:CpuDefinitionInfoList *arch_query_cpu_definitions(Error 
*arch_query_cpu_definitions(Error **errp)
target-s390x/cpu.c:CpuDefinitionInfoList *arch_query_cpu_definitions(Error 

arm walks through a list of all ARM CPU types
list = object_class_get_list(TYPE_ARM_CPU, false);
and returns the CpuDefinitionInfoList derived from that one to one

i386 loops over the static builtin_x86_defs[] array to retrieve the model names,
they don't even use the CPU class model as source

ppc walks through a list of all POWER CPU types
list = object_class_get_list(TYPE_POWERPC_CPU, false);
and then extends the produced list by all defined aliases

and s390x finally also walks through the defined S390 CPU types
list = object_class_get_list(TYPE_S390_CPU, false);
but drops those which are not usable (!is_active)
Just consider them as not defined. I actually would undefine
them if I knew how.

Also the commands comment says "list of supported virtual CPU definitions" and 
the s390
list contains all supported models, that's no contradiction.

So IMHO we can either

a) change the definition of query_cpu_definitions to only return CPUs that are executable with KVM on a given machine (probably a bad idea) or b) return not only the CPU type, but also a hint whether it's available with KVM or c) add a parameter to query_cpu_definitions to say "only return KVM runnable CPUs" or
  d) introduce a new query_kvm_cpu_definitions qmp command

# @query-cpu-definitions:
# Return a list of supported virtual CPU definitions
# Returns: a list of CpuDefInfo

The migration compatibility test is pretty much ARCH dependent. I looked into 
libvirt implementation and as one can see every architecture has its own 
there (libvirt/src/cpu/cpu_<arch>.c).
So here's my question again. How does x86 evaluate whether a target
machine is compatible with a source machine?
Will again look into that during the afternoon...

Yes, please. Someone else must have solved this before :).


reply via email to

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