From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7QdC-0004PC-5u for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:01:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7QdA-0003rw-KB for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:01:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49371) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7QdA-0003ra-2B for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:01:00 -0400 Date: Tue, 23 Jun 2015 17:00:54 +0100 From: "Daniel P. Berrange" Message-ID: <20150623160054.GK30318@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> <20150623155100.GJ30318@redhat.com> <20150623175407-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150623175407-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 05:56:35PM +0200, Michael S. Tsirkin wrote: > On Tue, Jun 23, 2015 at 04:51:00PM +0100, Daniel P. Berrange wrote: > > 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 wrote= : > > > > Am 08.06.2015 um 22:18 schrieb Jiri Denemark: > > > > >> To help libvirt in the transition, a x86-cpu-model-dump script= is provided, > > > > >> that will generate a config file that can be loaded using -rea= dconfig, based on > > > > >> the -cpu and -machine options provided in the command-line. > > > > >=20 > > > > > Thanks Eduardo, I never was a big fan of moving (or copying) al= l the CPU > > > > > configuration data to libvirt, but now I think it actually make= s sense. > > > > > We already have a partial copy of CPU model definitions in libv= irt > > > > > anyway, but as QEMU changes some CPU models in some machine typ= es (and > > > > > libvirt does not do that) we have no real control over the gues= t CPU > > > > > configuration. While what we really want is full control to enf= orce > > > > > stable guest ABI. > > > >=20 > > > > That sounds like FUD to me. Any concrete data points where QEMU d= oes not > > > > have a stable ABI for x86 CPUs? That's what we have the pc*-x.y m= achines > > > > for. > > >=20 > > > What Jiri is saying that the CPUs change depending on -mmachine, no= t > > > that the ABI is broken by a given machine. > > >=20 > > > The problem here is that libvirt needs to provide CPU models whose > > > 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, the VM should= be > > > still runnable in that host. QEMU doesn't provide that, our CPU mod= els > > > may change when we introduce new machine-types, so we are giving th= em a > > > mechanism that allows libvirt to implement the policy they need. > >=20 > > Expanding on that, but tieing the CPU model to the machine type, QEMU > > has in turn effectively tied the machine type to the host hardware. > > eg, switching to a newer machine type, may then prevent the guest > > from being able to launch on the hardware that it was previously > > able to run on, due to some new requirement of the CPU model associat= ed > > with the machine type. >=20 > So why not keep machine type stable? There are many reasons to choose a particular machine type - for example, to achieve migration compat between hosts with different QEMU versions, or to enable access to some performance or bug fix in the machine type in question. Users / apps need to be free to make those decisions, without being restricted by changes in the CPU model which may affect what hardware the machine type can be used on. The current use of machine types for CPU model versioning is placing users between a rock & hard place, giving them impossible decisions about which bad behaviour/bug they're willing to accept. 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 :|