Am 23.06.2015 um 18:32 schrieb Eduardo Habkost: > On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote: >> Am 23.06.2015 um 17:58 schrieb Eduardo Habkost: >>> On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote: >>>> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote: >>>>> On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote: >>>>>> Am 08.06.2015 um 22:18 schrieb Jiri Denemark: >>>>>>>> To help libvirt in the transition, a x86-cpu-model-dump script is >>>>>>>> provided, >>>>>>>> that will generate a config file that can be loaded using -readconfig, >>>>>>>> based on >>>>>>>> the -cpu and -machine options provided in the command-line. >>>>>>> >>>>>>> Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU >>>>>>> configuration data to libvirt, but now I think it actually makes sense. >>>>>>> We already have a partial copy of CPU model definitions in libvirt >>>>>>> anyway, but as QEMU changes some CPU models in some machine types (and >>>>>>> libvirt does not do that) we have no real control over the guest CPU >>>>>>> configuration. While what we really want is full control to enforce >>>>>>> stable guest ABI. >>>>>> >>>>>> That sounds like FUD to me. Any concrete data points where QEMU does not >>>>>> have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machines >>>>>> for. >>>>> >>>>> What Jiri is saying that the CPUs change depending on -mmachine, not >>>>> that the ABI is broken by a given machine. >>>>> >>>>> The problem here is that libvirt needs to provide CPU models whose >>>>> runnability does not depend on the machine-type. If users have a VM that >>>>> is running in a host and the VM machine-type changes, >>>> >>>> How does it change, and why? >>> >>> Sometimes we add features to a CPU model because they were not emulated by >>> KVM >>> and now they are. Sometimes we remove or add features or change other fields >>> because we are fixing previous mistakes. Recently we we were going to remove >>> features from models because of an Intel CPU errata, but then decided to >>> create >>> a new CPU model name instead. >>> >>> See some examples at the end of this message. >>> >>>> >>>>> the VM should be >>>>> still runnable in that host. QEMU doesn't provide that, our CPU models >>>>> may change when we introduce new machine-types, so we are giving them a >>>>> mechanism that allows libvirt to implement the policy they need. >>>> >>>> I don't mind wrt CPU specifically, but we absolutely do change guest ABI >>>> in many ways when we change machine types. >>> >>> All the other ABI changes we introduce in QEMU don't affect runnability of >>> the >>> VM in a given host, that's the problem we are trying to address here. ABI >>> changes are expected when changing to a new machine, runnability changes >>> aren't. >>> >>> >>> Examples of commits changing CPU models: >> [snip] >> >> I've always advocated remaining backwards-compatible and only making CPU >> model changes for new machines. You among others felt that was not >> always necessary, and now you're using the lack thereof as an argument >> to stop using QEMU's CPU models at all? That sounds convoluted... >> > > Uh? I don't remember anybody suggesting changing CPU models on existing > machines. We always tried to keep existing machines compatible.
Yes, we try in general. And in a few cases I was overruled, possibly related to TCG feature filtering or something. Thought that was the problem here - apparently not. Explanations seem to be the culprit here! >> BTW your list does not answer my question. You would need examples where >> a CPU model changes between machines, and I am not aware of any example >> beyond the intentional -x.y variations. There are differences between >> KVM and TCG though, did you mean that? i440fx and q35 should be >> identical and isa-pc, too, and none anyway. None of this has anything to >> do with the host CPU. > > We are talking about the -x.y variations (that, yes, are intentional). > But the fact that CPU features change (even the intentional ones in the > -x.y machine variations) affect runnability of VMs (because enabling new > CPU features in KVM require it to be supported by the host kernel code > and by the host CPU). > > I was not thinking about the KVM and TCG differences, but this may also > help libvirt deal with the KVM and TCG differences if necessary. > > I don't know what you mean by "i440fx and q35 should be identical" > above. In this thread there was a claim that CPU models varied between machine types. I am saying that there should be no CPU model differences between pc-i440fx-2.3 and pc-q35-2.3 etc. Thus the CPU model is not tied to one machine, but to the version of QEMU, with -x.y matching the corresponding release. No news to you, I would hope? Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg)