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 (jjhe...@linux.vnet.ibm.com)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to