From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RH4-00017U-N6 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:42:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7RH0-00079x-2g for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:42:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RGz-00079q-Rt for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:42:10 -0400 Date: Tue, 23 Jun 2015 17:42:04 +0100 From: "Daniel P. Berrange" Message-ID: <20150623164204.GM30318@redhat.com> References: <1433790460-30679-1-git-send-email-ehabkost@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150623183115-mutt-send-email-mst@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 Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" 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 =?utf-8?Q?F=C3=A4rber?= , 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: > > 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: > > > > On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrot= e: > > > >> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote: > > > >>> On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas F=C3=A4rber w= rote: > > > >>>> Am 08.06.2015 um 22:18 schrieb Jiri Denemark: > > > >>>>>> To help libvirt in the transition, a x86-cpu-model-dump scri= pt is provided, > > > >>>>>> that will generate a config file that can be loaded using -r= eadconfig, based on > > > >>>>>> the -cpu and -machine options provided in the command-line. > > > >>>>> > > > >>>>> Thanks Eduardo, I never was a big fan of moving (or copying) = all the CPU > > > >>>>> configuration data to libvirt, but now I think it actually ma= kes sense. > > > >>>>> We already have a partial copy of CPU model definitions in li= bvirt > > > >>>>> anyway, but as QEMU changes some CPU models in some machine t= ypes (and > > > >>>>> libvirt does not do that) we have no real control over the gu= est CPU > > > >>>>> configuration. While what we really want is full control to e= nforce > > > >>>>> stable guest ABI. > > > >>>> > > > >>>> That sounds like FUD to me. Any concrete data points where QEM= U does not > > > >>>> have a stable ABI for x86 CPUs? That's what we have the pc*-x.= y machines > > > >>>> for. > > > >>> > > > >>> What Jiri is saying that the CPUs change depending on -mmachine= , not > > > >>> that the ABI is broken by a given machine. > > > >>> > > > >>> The problem here is that libvirt needs to provide CPU models wh= ose > > > >>> runnability does not depend on the machine-type. If users have = a VM that > > > >>> is running in a host and the VM machine-type changes, > > > >> > > > >> How does it change, and why? > > > >=20 > > > > Sometimes we add features to a CPU model because they were not em= ulated by KVM > > > > and now they are. Sometimes we remove or add features or change o= ther fields > > > > because we are fixing previous mistakes. Recently we we were goin= g to remove > > > > features from models because of an Intel CPU errata, but then dec= ided to create > > > > a new CPU model name instead. > > > >=20 > > > > See some examples at the end of this message. > > > >=20 > > > >> > > > >>> the VM should be > > > >>> still runnable in that host. QEMU doesn't provide that, our CPU= models > > > >>> may change when we introduce new machine-types, so we are givin= g them a > > > >>> mechanism that allows libvirt to implement the policy they need= . > > > >> > > > >> I don't mind wrt CPU specifically, but we absolutely do change g= uest ABI > > > >> in many ways when we change machine types. > > > >=20 > > > > All the other ABI changes we introduce in QEMU don't affect runna= bility of the > > > > VM in a given host, that's the problem we are trying to address h= ere. ABI > > > > changes are expected when changing to a new machine, runnability = changes > > > > aren't. > > > >=20 > > > >=20 > > > > Examples of commits changing CPU models: > > > [snip] > > >=20 > > > I've always advocated remaining backwards-compatible and only makin= g 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 argum= ent > > > to stop using QEMU's CPU models at all? That sounds convoluted... > >=20 > > 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 situati= on > > because we want to be able to be able to access different versions of > > the CPU without the machine type changing, and access different versi= ons > > of the machine type, without the CPU changing. IOW it is the fact tha= t the > > changes in CPU are tied to changes in machine type that is the core > > problem. >=20 > 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. 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 :|