CCing Jiri Denemark, who maintains the CPU code in libvirt.

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:
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
any way when using a recent QEMU version?  Is the file considered
part of the libvirt API?

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to