[libvirt] What is the strategy to update the CPU Models in src/cpu/cpu_map.xml based on?
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? Thanks, dou
[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. Jirka
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? If we add a new CPU model, what we refer to? CPU models spec or hypervisors' code(eg, qemu-kvm) Thanks, dou
Jirka
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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?
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. Jirka
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
On Wed, May 30, 2018 at 19:25:53 +0800, Dou Liyang wrote:
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'.
And how is this different from what you wrote about in the original email?
BTW, QEMU code also didn't include it when add this CPU model.
What should we do?
You shouldn't need to do anything. If you start a domain with SandyBridge CPU model on QEMU which includes PCID in SandyBridge, your domain will get it too. As long as PCID can be provided on your host, of course. You can check that in the XML of the running domain (e.g., virsh dumpxml $DOM). You should see the pcid feature was added there. You can even request it explicitly if you want to have PCID enabled regardless what QEMU/libvirt think, but again the host, KVM, and QEMU have to be able to actually virtualize that feature. Jirka
At 05/30/2018 08:11 PM, Jiri Denemark wrote:
On Wed, May 30, 2018 at 19:25:53 +0800, Dou Liyang wrote:
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'.
And how is this different from what you wrote about in the original email?
BTW, QEMU code also didn't include it when add this CPU model.
What should we do?
You shouldn't need to do anything. If you start a domain with SandyBridge CPU model on QEMU which includes PCID in SandyBridge, your domain will get it too. As long as PCID can be provided on your host, of course. You can check that in the XML of the running domain (e.g., virsh dumpxml $DOM). You should see the pcid feature was added there.
You can even request it explicitly if you want to have PCID enabled regardless what QEMU/libvirt think, but again the host, KVM, and QEMU have to be able to actually virtualize that feature.
Hi Jirka, I understood. Thanks, dou
Jirka
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
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?
On Wed, May 30, 2018 at 12:55:19 -0300, Eduardo Habkost wrote:
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?
Yes, it is still used. Mainly for reporting host CPU capabilities (even those retrieved from QEMU), because we only get a list of features (both from QEMU and CPUID) and need to somehow choose a corresponding CPU model. And its also partially used to check whether a particular CPU can be provided on the host when we start a domain. But this checking is done mostly for backward compatibility and it is not very strict, the final decision of what can or cannot be used is on QEMU. In other words, we accept any feature which is either supported by the host CPU (using CPUID) or reported by QEMU as enabled for the "host" CPU model. Any requested features which cannot be provided by QEMU would just be disabled in the virtual CPU. This is of course all about the default check='partial'. Libvirt doesn't do any checks with check='full' and just asks QEMU whether it disabled any requested features.
Is the file considered part of the libvirt API?
The file format is not considered an API and it can change, but the CPU models, features and any other names defined there which can be used to describe a CPU are an API similarly to domain XML, for example. That is, each name has the same meaning across all versions of libvirt which support it. Jirka
participants (3)
-
Dou Liyang -
Eduardo Habkost -
Jiri Denemark