[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 -- libvir-list mailing list libvir-list(a)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

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

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?