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