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. > 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. -- Eduardo