> 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"
> >
> > <cpu mode='host-model'>:
> > - 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
