On Tue, Jun 23, 2015 at 06:47:16PM +0200, Andreas Färber wrote: > Am 23.06.2015 um 18:42 schrieb Daniel P. Berrange: > > 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. > >> > >> 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? > > > > Huh, I never said we wanted to bring back bugs. This is about allowing > > libvirt to fix the CPU bugs in a way that is independant of the machine > > types and portable across hypervisors we deal with. We're absolutely > > still going to fix CPU model bugs and ensure stable guest ABI. > > No, that's contradictory! Through the -x.y machines we leave bugs in the > old models *exactly* to assure a stable guest ABI. Fixes are only be > applied to new machines, thus I'm pointing out that you should not use a > new CPU model with an old machine type.
They don't need to use a new model with an old machine-type (although I don't see a reason to prevent that). They need to be able to change the machine-type to a new one without getting any changes that would make the VM not runnable in the same host. Even if it is a bug fix. If it is a change that can make the VM unrunnable, it needs to be controlled by a separate flag, not by the machine-type. -- Eduardo
