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

Dou Liyang douly.fnst at cn.fujitsu.com
Thu May 31 06:39:04 UTC 2018


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?

> 





More information about the libvir-list mailing list