Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models

[Eduardo Habkost]

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