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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
