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.
> Furthermore, the <mode name='custom'> section will list all supported
> model names, as indicated by qmp query-cpu-definitions. Do I have it
> right?
Mostly, the list of supported CPUs is filtered by libvirt so on some
architectures, the <mode name='custom'> section will list fewer models
than what you can get from QEMU.
> >> 2. virsh cpu-models {arch} will also use a Qemu invocation to gather
> >> cpu model data.
> >
> > No, virsh cpu-models will just list CPU models supported by libvirt
>
> So, in other words we just spit out whatever models Libvirt managed to
> grab, and cache, from a call to qmp query-cpu-definitions?
No. CPU models supported by libvirt are listed in cpu_map.xml. So we
have two basic sets of CPU models:
- A: models returned query-cpu-definitions
- B: models found in cpu_map.xml
Various interfaces report different sets:
- virsh cpu-models reports B
- <mode name='custom'> section of domain capabilities XML reports A ∩ B
> > (or an empty list if libvirt supports all models supported by QEMU).
>
> Can you clarify?
This is a special case of B being empty, which means libvirt does not
filter CPU models and any model supported by QEMU can be used with
libvirt. In this case, <mode name='custom'> section of domain
capabilities XML will contain A. But virsh cpu-models will report an
empty list.
...
> >> 4. virsh cpu-baseline and cpu-compare will now invoke qemu directly as
> >> well.
> >
> > Perhaps, but before we can do that, we'll probably need to come up with
> > new APIs. It don't think it's critical, though.
>
> Do you mind elaborating on this a bit? Which APIs do we want to look at
> here? Are you talking about new commands/calls to replace cpu-baseline
> and cpu-compare?
The virConnectCompareCPU, virConnectBaselineCPU don't have enough
parameters to be really useful. We'd need them to take more data (such
as emulator binary, domain type, and machine type) into account when
computing the results. But since we now provide CPU related data in
domain capabilities, I don't think it's critical to create new public
APIs for comparing CPUs. I think we may focus on the internals first.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list