On 09/23/2016 08:05 AM, Jiri Denemark wrote:
On Thu, Sep 22, 2016 at 14:47:36 -0400, Jason J. Herne wrote:
...
1. We will invoke qemu to gather the host cpu data used for virsh
capabilities. Today this data seems to be collected directly from the
host hardware for most (all?) architectures.
Not really, virsh capabilities will still contain data gathered directly
from the host hardware. But, we have virsh domcapabilities for
displaying data tight to a specific QEMU binary. Since yesterday
afternoon we have support for displaying CPU related data in the domain
capabilities XML; see
http://libvirt.org/formatdomaincaps.html#elementsCPU
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. 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'. Furthermore, the
<mode name='custom'> section will list all supported model names, as
indicated by qmp query-cpu-definitions. Do I have it right?
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? Or am I
missing something?
(or an empty list if libvirt supports all models supported by QEMU).
Can you clarify? It seems odd that an empty list would be returned here.
I thought the point was to list all supported cpu models. For x86 today
I imagine it is the list found in cpu_map.xml. For s390, this will be
the list we get back from qmp query-cpu-definitions, which as you mention
below, is found in the domain capabilities XML.
The CPU model data from QEMU can be found in domain capabilities XML.
3. Most architectures seem to use a "map" (xml file containing cpu
model data that ships with Libvirt) to satisfy #1 and #2 above. Our
new method does not use this map as it gets all of the data directly
from Qemu.
Even if we switch some CPU operations to work through QEMU, we may still
need to use the cpu_map.xml file for some other operations, or other
hypervisor driver. It all depends on what we need to do for a given
architecture. For example, ARM does not use cpu_map.xml at all even now.
Slightly related, I don't think we have a way to list CPU features
supported by QEMU over QMP, do we? "-cpu ?" will show them all, but I
couldn't find a QMP command that would give me the same list.
query-model-expansion will return all features of a given model name. Model
names can be enumerated via query-cpu-definitions.
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?
Thanks again for your time.
--
-- Jason J. Herne (jjherne@xxxxxxxxxxxxxxxxxx)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list