1:51 a.m.
On Tue, Jun 21, 2016 at 17:33:09 -0300, Eduardo Habkost wrote:
> 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.
What libvirt is really interested in is the guest CPU which would be
used with -cpu host. This is actually what I thought query-host-cpu was
all about. Perhaps because there's no difference for x86.
That's also what I had in mind first. Let me explain why they are not the same
on s390x and why it is problematic (actually both types are not the same!):
1. Certain CPU features are only valid for LPAR guests, they can't be
virtualized for KVM guests (remember that we always have at least one level of
virtualization on s390x). So we will never be able to provide these features to
a KVM guest, therefore we will never be able to completely mimic the real host
model.
2. We have a whole lot of unpublished features. We would have to include them in
the "real host model", but we can't. For the "host" model, this is
not a
problem, because we simply don't virtualize them. But the "real host model"
would then vary between say QEMZ versions, which looks really strage, because
in essance, QEMU/KVM looks like the wrong interface to query for a "real host
model".
3. We don't have the kernel interfaces in place to query the "real host
model".
We can only query what we are able to virtualize. And that is indeed different
compared to what I said previously.
And as I can't see any use case for s390x, we most probably will never be able
to support the interface you are suggesting here. Which is fine, if it makes
sense for x86.
> 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.
I think we can just easily get around this by not comparing a guest CPU
to host (except for the explicit virConnectCompareCPU, which is not very
useful in its current form anyway).
If there is some flexible way around that, great. But I think we (s390x) could
life without this additional query.
So your first concern is valid, and if you really need this information, you
should probably really create a new interface. Your second concern should not
be trivial for now. We don't want to optimize for total speed at that point.
David