[libvirt] What is the strategy to update the CPU Models in src/cpu/cpu_map.xml based on?

[Dou Liyang]

Hi Jiri,

At 05/30/2018 07:08 PM, Jiri Denemark wrote:
> On Wed, May 30, 2018 at 18:55:02 +0800, Dou Liyang wrote:
>> Hi Jiri,
>>
>> At 05/30/2018 06:14 PM, Jiri Denemark wrote:
>>> [Dropping random people from Cc]
>>>
>>> On Wed, May 30, 2018 at 18:00:56 +0800, Dou Liyang wrote:
>>>> Hi All,
>>>>
>>>> I am not sure about the update strategy of CPU models in libvirt.
>>>>
>>>> IMO, It's depend on the CPU model in qemu-kvm, if some CPU models
>>>> were updated in qemu-kvm. Then, we should modify the src/cpu/cpu_map.xml
>>>> of libvirt to synchronize?
>>>
>>> No, we never change existing CPU models in cpu_map.xml to make sure the
>>> same CPU model is the same across libvirt versions. Not to mention that
>>> QEMU only changes existing CPU models for new machine type (for the same
>>> compatibility reason) so we can't just change our CPU models since we
>>> don't know what machine type their going to be used with. Libvirt will
>>> handle the differences in runtime by remembering any additionally
>>> enabled or disabled features once domain starts to make sure the exact
>>> same CPU is recreated after, e.g., migration.
>>>
>>
>> I see.
>>
>> Btw, If we found there is a wrong feature in the existing CPU models,
>> what should we do?
> 
> What do you mean by wrong feature?

In other words, a missing feature. We met a case:

   The CPU model named SandyBridge has the PCID feature.
   but, in the src/cpu/cpu_map.xml:999, the SandyBridge entry
       <model name='SandyBridge'>
         ...
       </model>

   ... didn't included the 'pcid'.

BTW, QEMU code also didn't include it when add this CPU model.

What should we do?

> 
>> If we add a new CPU model, what we refer to? CPU models spec or
>> hypervisors' code(eg, qemu-kvm)
> 
> QEMU code for CPU model and if new CPUID features are required for that
> model the CPU vendor's specification of the new features is useful too.
> 

I see

Thanks,
	dou.

> Jirka
> 
> 
>