[libvirt] Cpu Modeling

[Jason J. Herne]

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 at linux.vnet.ibm.com)