Hi Eduardo, At 05/30/2018 11:55 PM, Eduardo Habkost wrote:
CCing Jiri Denemark, who maintains the CPU code in libvirt.
Thanks, Jirka. he has already given me a detailed explanation. ;-)
On Wed, May 30, 2018 at 06:00:56PM +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?
eg:
commit cad8054ece28("cpu: Add cpu definition for Intel Sandy Bridge cpu type") in libvirt upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=761005
If it's right, I found this commit b3a4f0b1a072("target-i386: add VME to all CPUs") updated the VME feature in qemu upstream. But in the src/cpu /cpu_map.xml of libvirt, It didn't be updated.
eg: For the SandyBridge CPU,
- In QEmu, it has the 'vme' feature defined by CPUID_VME
- In libvirt, it doesn't has the 'vme' in cpu_map.xml file.
Why?
I don't know the specifics, but I think libvirt can't change CPU models in cpu_map.xml. However, this shouldn't be a problem:
I see, Jirka also told me that.
libvirt should use "-cpu SandyBridge" and users should still benefit from the updated CPU definition in QEMU.
The main question that I'm still unable to answer is: when cpu_map.xml is still used? Does it affect libvirt behavior in
I tried to find, but I don't know, The call stack in libvirt upstream shows below cpu_map.xml <-- cpuMapLoad() <-- virCPUx86LoadMap() <-- virCPUx86DriverOnceInit() I even don't find where virCPUx86DriverOnceInit() is used and where is the definition of virCPUx86DriverInitialize(). :-( Thanks, dou
any way when using a recent QEMU version? Is the file considered part of the libvirt API?