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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
