From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RlQ-0008N4-3S for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:13:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7RlK-0005Gy-4b for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:13:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RlJ-0005Gp-Sy for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:13:30 -0400 Date: Tue, 23 Jun 2015 18:13:24 +0100 From: "Daniel P. Berrange" Message-ID: <20150623171324.GO30318@redhat.com> References: <20150608201835.GM3525@orkuz.home> <558951C0.3050806@suse.de> <20150623150828.GD3134@thinpad.lan.raisama.net> <20150623173048-mutt-send-email-mst@redhat.com> <20150623155832.GE3134@thinpad.lan.raisama.net> <55898637.6080804@suse.de> <20150623162555.GL30318@redhat.com> <20150623183115-mutt-send-email-mst@redhat.com> <20150623164204.GM30318@redhat.com> <55898D94.4070702@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55898D94.4070702@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: mimu@linux.vnet.ibm.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , rth@twiddle.net, Eduardo Habkost On Tue, Jun 23, 2015 at 06:47:16PM +0200, Andreas F=C3=A4rber 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=C3=A4rber wrote= : > >>>> Am 23.06.2015 um 17:58 schrieb Eduardo Habkost: > >>>> I've always advocated remaining backwards-compatible and only maki= ng 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 argu= ment > >>>> 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 situa= tion > >>> because we want to be able to be able to access different versions = of > >>> the CPU without the machine type changing, and access different ver= sions > >>> of the machine type, without the CPU changing. IOW it is the fact t= hat 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? > >=20 > > Huh, I never said we wanted to bring back bugs. This is about allowin= g > > libvirt to fix the CPU bugs in a way that is independant of the machi= ne > > types and portable across hypervisors we deal with. We're absolutely > > still going to fix CPU model bugs and ensure stable guest ABI. >=20 > No, that's contradictory! Through the -x.y machines we leave bugs in th= e > 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 --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|