Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

[Eduardo Habkost]

On Tue, Jun 21, 2016 at 07:01:44PM +0200, David Hildenbrand wrote:
> > (CCing libvirt people)
> > 
> > On Tue, Jun 21, 2016 at 03:02:05PM +0200, David Hildenbrand wrote:
> > > 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.  
> > 
> > Before getting into the details, I would like to clarify how the
> > following could be accomplished using the new commands:
> > 
> > Example:
> > 
> > 1) User configures libvirt with:
> >    <cpu match='exact'>
> >        <model fallback='forbid'>Westmere</model>
> >        <feature policy='require' name='aes'/>
> >    </cpu>
> > 2) libvirt will translate that to:
> >    "-cpu Westmere,+aes" or "-cpu Westmere,aes=on"
> > 3) libvirt wants to know if "-cpu Westmere,aes=on" is usable in
> >    the current host, before trying to start the VM.
> > 
> > How exactly would this be done using the new commands?
> 
> Hi Eduardo,
> 
> thanks for having a look - highly appreciated that you actually map this
> to libvirt requirements!
> 
> That would map to a compare operation between "host" and "Westmere,aes=on".
> 
> Host could at that point already be expanded by libvirt. Doesn't matter at 
> that
> point.
> 
> If the result is "identica"l or "superset", it is runnable. If the result is
> "subset" or "incompatible", details about the responsible properties is
> indicated. (I actually took that idea from your patch for indicating
> runnability).

So, I have two worries about the proposal:


1) "query-cpu-model-expansion model=host" vs "query-host-cpu":

I still don't think we want to set in stone that "the result the
guest sees when using -cpu host" is always the same as "what the
host supports running".

For example: let's assume a given architecture have two features
(A and B) that are both supported by the host but can never be
enabled together. For actual "-cpu host" usage, QEMU would have
to choose between enabling A and B. For querying host
capabilities, we still want to let management software know that
either A or B are supported.

If we don't mind adding multiple new QMP commands in this series,
I don't see why not having a separate "query-host-cpu" command so
the semantics of each command are very clear. Then
query-cpu-definitions/query-cpu-model-expansion would be about
"what you really get when using -cpu <model>", and
"query-host-cpu" would be about "what this hosts supports
running".


2) Requiring a running QEMU instance to run
   query-cpu-model-comparison

With my previous query-host-cpu proposal, the task of comparing
the configuration requested by the user with host capabilities
can be done directly by libvirt. This way, no extra QEMU instance
needs to be run before starting a VM.

In my example above, if query-cpu-model-comparison were not
required, libvirt could run "query-cpu-expansion model=host" or
"query-host-cpu" once at boot, and just check if "Westmere" is
runnable and "aes" is present in the host data. With
query-cpu-model-comparison, QEMU needs to be run one more time
before starting a VM.

I don't know if requiring running a new QEMU instance just to
check if a CPU config is runnable would be acceptable for
libvirt. I will let the libvirt people answer that.

I still like the query-cpu-model-comparison proposal, because it
would allow us to extend the data returned by
query-cpu-model-expansion without requiring libvirt changes. It
may be the best log-term option, but probably only after we add a
mechanism to allow the VM to be configured after running a few
QMP commands, without re-running QEMU.

-- 
Eduardo