
Polite Ping? :) On 09/23/2016 03:51 PM, Jason J. Herne wrote:
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@linux.vnet.ibm.com)