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

[Michael S. Tsirkin]

On Tue, Jun 23, 2015 at 06:13:24PM +0100, Daniel P. Berrange wrote:
> 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:
> > >>>> 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.
> 
> I'm not saying that libvirt would ever allow a silent guest ABI change.
> Given a libvirt XML config, the guest ABI will never change without an
> explicit action on the part of the app/user to change the XML.
> 
> This is all about dealing with the case where the app / user conciously
> needs/wants to opt-in to a guest ABI change for the guest. eg they wish
> to make use of some bug fix or feature improvement in the new machine
> type, but they do *not* wish to have the CPU model changed, because
> of some CPU model change that is incompatible with their hosts' CPUs.
> Conversely, they may wish to get access to a new CPU model, but not
> wish to have the rest of the guest ABI change. In both cases the user
> is explicitly opt-ing in the ABI change with knowledge about what
> this might mean for the guest OS. Currently we are tieing users
> hands by forcing CPU and machine types to change in lockstep.
> 
> Regards,
> Daniel

Can we have a specific example please?  It's hard to understand the
facts based on such generic statements.


> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|