On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote: > On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote: > > 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... > > > > Whether QEMU changed the CPU for existing machines, or only for new > > machines is actually not the core problem. Even if we only changed > > the CPU in new machines that would still be an unsatisfactory situation > > because we want to be able to be able to access different versions of > > the CPU without the machine type changing, and access different versions > > of the machine type, without the CPU changing. IOW it is the fact that the > > changes in CPU are tied to changes in machine type that is the core > > problem. > > > > Regards, > > Daniel > > But that's because we are fixing bugs. If CPU X used to work on > hardware Y in machine type A and stopped in machine type B, this is > because we have determined that it's the right thing to do for the > guests and the users. We don't break stuff just for fun. > Why do you want to bring back the bugs we fixed?
I didn't take the time to count them, but I bet most of the commits I listed on my previous e-mail message are not bug fixes, but new features. Also, it doesn't matter if the change is a bug fix or a new feature: if it affects runnability of the VM, it has more consequences than a simple guest-side ABI change, and libvirt can't tie it to the machine-type so it needs another flag to enable it. -- Eduardo
