On Tue, Jun 23, 2015 at 07:18:06PM +0200, Andreas Färber wrote: > Am 23.06.2015 um 19:08 schrieb Eduardo Habkost: > > On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas Färber wrote: > >> Am 23.06.2015 um 18:38 schrieb Eduardo Habkost: > >>> 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: > >>>>> 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? > >>> > >>> 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. > >> > >> Huh? Of course the latest machine model get new features. The point is > >> that the previous ones don't and that's what we are providing them for - > >> libvirt is expected to choose one machine and the contract with QEMU is > >> that for that machine the CPU does *not* grow new features, and we're > >> going at great lengths to achieve that. So this thread feels more and > >> more weird... > > > > We are not talking about changes to existing machines. We are talking > > about having changes introduced in new machines (the one we did on > > purpose) affecting the runnability of the VM. > > You are talking abstract!
I am just talking about a different problem, and I don't know if you are purposely trying to ignore it, or are just denying that it is a problem. > > > Example 1: > > Point A: Machine pc-i440fx-2.3 exists > > Runs or runs not. > > Point B: Machine pc-i440fx-2.3 still exists > > Still runs or runs not due to guest ABI stability rules. If you didn't change the machine name, this is not the problem we are talking about. > > > Example 2: > > Point A: pc-i440fx-2.4 does not exist in 2.3 > > Does not run becomes it doesn't exist. > > Point B: New pc-i440fx-2.4 > > Runs or does not run, and if so has more features than pc-i440fx-2.3. If you didn't change the machine name, this is not the problem we are talking about. > > There is no runnability problem - either it runs or it doesn't, but > there's no change over time. > > This is what the machine -x.y versioning is all about. Let's try a concrete example: * User is running a kernel that can't emulate x2apic * User is running pc-i440fx-1.7 * User wants the gigabyte alignment change implemented by commit bb43d3839c29b17a2f5c122114cd4ca978065a18 * User changes machine to pc-i440fx-2.0 * x2apic is now enabled by default in all CPU models * VM with the same configuration (just the machine change) is not runnable anymore in the same host -- Eduardo
