On 09/29/2016 11:15 AM, Jiri Denemark wrote:
On Fri, Sep 23, 2016 at 15:51:12 -0400, Jason J. Herne wrote:
On 09/23/2016 08:05 AM, Jiri Denemark wrote:
The host-model part of the XML will show the result of
query-cpu-model-expansion on "host" model, or the result of querying the
hardware directly if we can't ask QEMU for that (which is the current
So the expectation here is that virsh capabilities" reports actual host
cpu data. So for S390, we can leave our implementation of this "as-is"
and not report any features here, I'm guessing.
And the <cpu> section from virsh domcapabilities will contain the Qemu
specific supported cpu modeling info. As you stated <mode
name='host-model'> will contain the name (and possibly feature
details?) of the model returned by qmp query-model-expansion on
Right, the host-model part should basically contain the CPU
configuration which libvirt will use if a user asks for host-model. For
example (on x86_64, since I have no experience with s390), the following
<mode name='host-model' supported='yes'>
<feature policy='require' name='vmx'/>
<feature policy='require' name='tsc_adjust'/>
would result in "-cpu Skylake-Client,+vmx,+tsc_adjust" QEMU command line.
In order to properly obtain the host cpu model data for virsh
s390 we will need to run a Qemu process. There is no precedent for doing
in a cpu connection driver today. I can imagine two ways to do this:
1. The s390 cpu connection driver (src/cpu/cpu_s390.c) can just
use of the default Qemu binary and the appropriate qmp calls can be made to
get the model name and possibly features.
2. We can extend the existing interface somehow so all archs could make
a hypervisor instance for nodeData() and decode() operations. Perhaps a
of callbacks? nodeDataWithHypervisor(), decodeWithHypervisor() ? We'd
modify the generic versions of these functions to try one set of interfaces,
then the other in case the first set is not supported for a given arch.
Do either of these sound sane to you, or am I way off on this?
I'm trying to get the host cpu model for virCapsPtr caps, as it is filled in
via virQEMUCapsInit --> virQEMUCapsInitCPU. And subsequently referenced for
the output of virsh capabilities and copied into qemuCaps for reference by
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)
libvir-list mailing list