qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Patch v1 00/29] s390x CPU models: exposing features


From: David Hildenbrand
Subject: Re: [Qemu-devel] [Patch v1 00/29] s390x CPU models: exposing features
Date: Tue, 2 Aug 2016 20:12:34 +0200

> 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




reply via email to

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