Re: [Qemu-devel] [Patch v1 00/29] s390x CPU models: exposing features
On Tue, Aug 02, 2016 at 08:12:34PM +0200, David Hildenbrand wrote: > > On Tue, Aug 02, 2016 at 01:58:46PM +0200, David Hildenbrand wrote: > > [...] > > > So we have: > > > a) "query-cpu-model-expansion" - tell us what the "host" or another CPU > > >model looks like. Either falling back to a static model or > > >completely exposing all properties. > > > > The query-cpu-model-expansion interface looks good to me. I just > > had a few comments about the interface documentation. > > > > > b) "query-cpu-model-comparison" - tell us how two CPU models compare, > > > indicating which properties were responsible for the decision. > > > c) "query-cpu-model-baseline" - create a new model out of two models, > > > taking a requested level of stability into account. > > > > I miss a clearer specifiction of what are the actual requirements > > and use cases of query-cpu-model-baseline. Is it related to > > runnability? If so, how exactly? > > cpu-baseline and cpu-compare are only needed to make > - "virsh cpu-compare" > - "virsh cpu-baseline" work > (see libvirt usecases below) > > These commands are needed to find/test runnability of a CPU model for > a cluster in bigger installations by tooling. > > As libvirt won't have details about s390x models, we have to provide > an interface so it can carry out these tasks. > > > > > Related to that (as mentioned in my reply to patch 25/29), I > > would like a clearer definintion of what "superset" and "subset" > > mean exactly, in query-cpu-model-comparison. Likewise, I would > > like to understand the requirements and use cases that make > > "superset" and "subset" useful. > > I took these definitions from libvirt directly. > > Example: core2duo against my sandybridge > $ virsh cpu-compare test.xml > Host CPU is a superset of CPU described in test.xml > > Usually, you do a "virsh cpu-compare" against your host cpu model. Chances > that the result is identical are very low. So depending on which > one is the first model, you get superset or subset. > > So > if A is a subset of B, A will run where B runs > if A is a superset of B, B will run where A runs > > That means, if "cpu-compare" (against your host!) returns "identical" or > "superset", you're good to go. If they are "incompatible" or "subset", > you will have to use cpu-baseline to create a compatible model. > > Does that answer your question? It does, thanks! We need this to be clearly specified in the QMP command documentation. Proably the "if A is a superset of B, [...]" rule is enough to unambigiously specify the semantics, while the rest of your explanation is useful to explain when/how exactly the command is useful. -- Eduardo
Re: [Qemu-devel] [Patch v1 00/29] s390x CPU models: exposing features
> On Tue, Aug 02, 2016 at 01:58:46PM +0200, David Hildenbrand wrote:
> [...]
> > So we have:
> > a) "query-cpu-model-expansion" - tell us what the "host" or another CPU
> >model looks like. Either falling back to a static model or
> >completely exposing all properties.
>
> The query-cpu-model-expansion interface looks good to me. I just
> had a few comments about the interface documentation.
>
> > b) "query-cpu-model-comparison" - tell us how two CPU models compare,
> > indicating which properties were responsible for the decision.
> > c) "query-cpu-model-baseline" - create a new model out of two models,
> > taking a requested level of stability into account.
>
> I miss a clearer specifiction of what are the actual requirements
> and use cases of query-cpu-model-baseline. Is it related to
> runnability? If so, how exactly?
cpu-baseline and cpu-compare are only needed to make
- "virsh cpu-compare"
- "virsh cpu-baseline" work
(see libvirt usecases below)
These commands are needed to find/test runnability of a CPU model for
a cluster in bigger installations by tooling.
As libvirt won't have details about s390x models, we have to provide
an interface so it can carry out these tasks.
>
> Related to that (as mentioned in my reply to patch 25/29), I
> would like a clearer definintion of what "superset" and "subset"
> mean exactly, in query-cpu-model-comparison. Likewise, I would
> like to understand the requirements and use cases that make
> "superset" and "subset" useful.
I took these definitions from libvirt directly.
Example: core2duo against my sandybridge
$ virsh cpu-compare test.xml
Host CPU is a superset of CPU described in test.xml
Usually, you do a "virsh cpu-compare" against your host cpu model. Chances
that the result is identical are very low. So depending on which
one is the first model, you get superset or subset.
So
if A is a subset of B, A will run where B runs
if A is a superset of B, B will run where A runs
That means, if "cpu-compare" (against your host!) returns "identical" or
"superset", you're good to go. If they are "incompatible" or "subset",
you will have to use cpu-baseline to create a compatible model.
Does that answer your question?
>
> >
> > Libvirt usecase
> >
> > Testing for runability:
> > - Simply try to start QEMU with KVM, compat machine, CPU model
> > - Could be done using query-cpu-model-comparison in the future.
> >
> > Identifying host model, e.g. "virsh capabilities"
> > - query-cpu-model-expansion on "host" with "-M none --enable-kvm"
> >
> > :
> > - simply copy the identified host model
>
> AFAICS, this will work out of the box only if
> query-cpu-model-expansion {name: "host"}
> return a static CPU model name in return.model.name.
Yes, that was also my impression.
Thanks again!
David
Re: [Qemu-devel] [Patch v1 00/29] s390x CPU models: exposing features
On Tue, Aug 02, 2016 at 01:58:46PM +0200, David Hildenbrand wrote:
[...]
> So we have:
> a) "query-cpu-model-expansion" - tell us what the "host" or another CPU
>model looks like. Either falling back to a static model or
>completely exposing all properties.
The query-cpu-model-expansion interface looks good to me. I just
had a few comments about the interface documentation.
> b) "query-cpu-model-comparison" - tell us how two CPU models compare,
> indicating which properties were responsible for the decision.
> c) "query-cpu-model-baseline" - create a new model out of two models,
> taking a requested level of stability into account.
I miss a clearer specifiction of what are the actual requirements
and use cases of query-cpu-model-baseline. Is it related to
runnability? If so, how exactly?
Related to that (as mentioned in my reply to patch 25/29), I
would like a clearer definintion of what "superset" and "subset"
mean exactly, in query-cpu-model-comparison. Likewise, I would
like to understand the requirements and use cases that make
"superset" and "subset" useful.
>
> Libvirt usecase
>
> Testing for runability:
> - Simply try to start QEMU with KVM, compat machine, CPU model
> - Could be done using query-cpu-model-comparison in the future.
>
> Identifying host model, e.g. "virsh capabilities"
> - query-cpu-model-expansion on "host" with "-M none --enable-kvm"
>
> :
> - simply copy the identified host model
AFAICS, this will work out of the box only if
query-cpu-model-expansion {name: "host"}
return a static CPU model name in return.model.name.
>
> :
> - "-cpu host"
>
> "virsh cpu-baseline":
> - query-cpu-model-baseline on two models with "-M none"
>
> "virsh cpu-compare":
> - query-cpu-model-comparison on two models with "-M none"
>
> There might be some cenarios where libvirt wants to convert another CPU
> model to a static variant, this can be done using query-cpu-model-expansion
>
[...]
--
Eduardo
[Qemu-devel] [Patch v1 00/29] s390x CPU models: exposing features
After a very helpful discussion with Eduardo, we I did some changes to the
patch series, the most important ones being:
- All models except "host" will be "migration-safe" on s390x
- CPU model expansion now has only two types "full" and "static"
- The parameter "type" from CPU model baseline has been dropped
- "query-cpu-definitions" is extended by "static" and "migration-safe"
- Updated + clarified description of new QMP interfaces
Full list of changes can be found at the end of this length cover letter.
Latest version can be found on branch:
github.com/cohuck/qemu cpumodel-s390x-v1
Concept
This is our second attempt to implement CPU models for s390x. We realized
that we also want to have features exposed via the CPU model. While doing
that we realized that we want to have a better interface for libvirt.
Unfortunately, CPU models on s390x are special and we have to take care of:
- A CPU like z13 looks differently in various environments (under different
LPAR versions, under different z/VM versions, under different KVM
versions, export regulation) - we have _a lot_ of feature variability.
- We still have certain features that are not published but might be
implemented/introduced in the future. As they are a theoretical part
of a CPU already, we have to find a way to model these future changes.
- We still have certain features that are already published, but not
implemented. Implementation might be added in the future in KVM.
- We heavily rely on KVM to tell us which features it can actually
virtualize - user space queries like "STFL(e)" give no guarantees.
- Certain "subfeatures" were introduced in one run. In practice, they are
always around, but in theory, subfeatures could be dropped in the future.
- Just because two CPU models have the same features doesn't mean they
are equal - some internal numbers might be different. E.g. we won't allow
running a z13 under a zBC12 just by turning off features.
- We cannot blindly enable all possible features for a CPU generation,
the IBC "Instruction Blocking Control" in KVM will try to block
instructions introduced with certain features. So a CPU generation always
has some maximum feature set that is guaranteed to work.
It all boils down to a specific released CPU to have.
a) A minimum feature set that we expect it to be have on every hypervisor.
b) A variable part that depends on the hypervisor and that could be
extended in the future (adding not yet implemented features) that we
always want to enable later on.
c) A variable part that we want to enable only if requested - nested
virtualization ("vsie") and assists are one example.
As we want our users to always make use of most features, e.g. when using
the "z13" CPU model, we will have to update our CPU models between QEMU
releases, to include the latest feature additions we implemented/unlocked.
We're badically trying to be able at one point in the future to really look
like a maximum "z13" CPU in QEMU. However, that means that a "z13" CPU
looks differently on different QEMU versions. We will make sure using
compatibility machines, that migration stays safe.
However, if the feature set of a CPU model is bound to a compatibility
machine, how can it be of any help when used without a compatibility
machine? E.g. when indicating the host CPU model in "virsh capabilities",
simply saying "z13" is not really clear. Also when baselining and
comparing CPU models, we usually have no compatibility machine "context"
at hand. For this reason we introduce "static" CPU models, which will
never change, so everybody knows without a compatibility machine, what we
are talking about.
CPU definitions/models can be categorized:
1. migratable: all features _can_ be identified + properly migrated.
--> With migratable=off on x86, "host" cannot be migrated properly.
2. migration-safe: in combination with a QEMU machine, migration will work.
--> No CPU features are lost/added during migration
3. static: not bound to a QEMU machine - featureset will never* change.
--> Everybody knows which features are part of it, not affected by a compat
machine. "virsh capabilities" can show this as "host" model.
*except for trivial bugfixes, especially on very old models nobody used in
production. Should be avoided.
We are currently planning to also support a "migratable=off" on s390x
for the "-cpu host" model, in order to enable all features, including not
recognized ones.
So we have on s390x:
a) A static CPU model for each released CPU that will never change and
maps to the minimum feature set we expect to be around on all
hypervisors. e.g. "z13-base" or "z10EC.2-base".
b) A "default" CPU model for each released CPU, that can change between
QEMU versions and that will always include the features we expect to
be around in our currently supported environments and will contain only
features we expect to be stable. E.g.
