From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Via-0005qj-Pi for qemu-devel@nongnu.org; Tue, 23 Jun 2015 17:26:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7ViX-0002u5-2I for qemu-devel@nongnu.org; Tue, 23 Jun 2015 17:26:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7ViW-0002ty-SG for qemu-devel@nongnu.org; Tue, 23 Jun 2015 17:26:53 -0400 Date: Tue, 23 Jun 2015 23:26:48 +0200 From: "Michael S. Tsirkin" Message-ID: <20150623232611-mutt-send-email-mst@redhat.com> References: <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> <20150623171324.GO30318@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20150623171324.GO30318@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , rth@twiddle.net, Andreas =?iso-8859-1?Q?F=E4rber?= , Eduardo Habkost 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=E4rber 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=E4rber wrote: > > >>>> Am 23.06.2015 um 17:58 schrieb Eduardo Habkost: > > >>>> I've always advocated remaining backwards-compatible and only ma= king CPU > > >>>> model changes for new machines. You among others felt that was n= ot > > >>>> always necessary, and now you're using the lack thereof as an ar= gument > > >>>> to stop using QEMU's CPU models at all? That sounds convoluted..= . > > >>> > > >>> Whether QEMU changed the CPU for existing machines, or only for n= ew > > >>> machines is actually not the core problem. Even if we only change= d > > >>> the CPU in new machines that would still be an unsatisfactory sit= uation > > >>> because we want to be able to be able to access different version= s of > > >>> the CPU without the machine type changing, and access different v= ersions > > >>> 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 co= re > > >>> 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 i= s > > >> 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 allow= ing > > > libvirt to fix the CPU bugs in a way that is independant of the mac= hine > > > types and portable across hypervisors we deal with. We're absolutel= y > > > 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 = 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 us= e a > > new CPU model with an old machine type. >=20 > 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. >=20 > 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. >=20 > Regards, > Daniel Can we have a specific example please? It's hard to understand the facts based on such generic statements. > --=20 > |: http://berrange.com -o- http://www.flickr.com/photos/dberran= ge/ :| > |: http://libvirt.org -o- http://virt-manager.= org :| > |: http://autobuild.org -o- http://search.cpan.org/~danbe= rr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-= vnc :|