[libvirt] [RFC 00/28] s390x CPU models: exposing features

[Jiri Denemark]

On Wed, Jun 22, 2016 at 08:51:40 +0200, David Hildenbrand wrote:
> > 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:  
> > > 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.

Well, as I said I always thought about query-host-cpu as a way to get
the CPU configuration QEMU would provide with -cpu host. Thanks to this
discussion I realized its semantics is different and thus what I really
need is actually the command you suggested, i.e.,
query-cpu-model-expansion.

> > > 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 if I understand correctly, you say you don't need the API to compare
guest CPU to host CPU, right? If so, that's exactly what I said too.

Jirka