Re: [libvirt] Cpu Modeling
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
>> state).
>
> 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.
Yes.
> 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
> 'host'.
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
XML
<mode name='host-model' supported='yes'>
<model fallback='forbid'>Skylake-Client</model>
<vendor>Intel</vendor>
<feature policy='require' name='vmx'/>
<feature policy='require' name='tsc_adjust'/>
</mode>
would result in "-cpu Skylake-Client,+vmx,+tsc_adjust" QEMU command line.
Jiri,
In order to properly obtain the host cpu model data for virsh
capabilities on
s390 we will need to run a Qemu process. There is no precedent for doing
this
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
privately make
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
use of
a hypervisor instance for nodeData() and decode() operations. Perhaps a
new set
of callbacks? nodeDataWithHypervisor(), decodeWithHypervisor() ? We'd
have to
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
virsh domcapabilities.
--
-- Jason J. Herne (jjherne(a)linux.vnet.ibm.com)