From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53863) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7R68-0006mI-Vn for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:30:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7R63-0002FD-Uz for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:30:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7R63-0002Eo-Oc for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:30:51 -0400 Date: Tue, 23 Jun 2015 18:30:46 +0200 From: "Michael S. Tsirkin" Message-ID: <20150623182537-mutt-send-email-mst@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> <20150623160054.GK30318@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20150623160054.GK30318@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 05:00:54PM +0100, Daniel P. Berrange wrote: > 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=E4rber wrote: > > > > > 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. > > > > > >=20 > > > > > > 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. > > > > >=20 > > > > > That sounds like FUD to me. Any concrete data points where QEMU= does not > > > > > have a stable ABI for x86 CPUs? That's what we have the pc*-x.y= machines > > > > > for. > > > >=20 > > > > What Jiri is saying that the CPUs change depending on -mmachine, = not > > > > that the ABI is broken by a given machine. > > > >=20 > > > > The problem here is that libvirt needs to provide CPU models whos= e > > > > 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 shou= ld be > > > > still runnable in that host. QEMU doesn't provide that, our CPU m= odels > > > > may change when we introduce new machine-types, so we are giving = them a > > > > mechanism that allows libvirt to implement the policy they need. > > >=20 > > > Expanding on that, but tieing the CPU model to the machine type, QE= MU > > > 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 associ= ated > > > with the machine type. > >=20 > > So why not keep machine type stable? >=20 > There are many reasons to choose a particular machine type - for > example, to achieve migration compat between hosts with different > QEMU versions, This might make you use an old machine type. It will never make you use a newer machine type so you will never run into problems. > or to enable access to some performance or bug > fix in the machine type in question. Performance/bugfixes is exactly why we change these though. > 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. >=20 > Regards, > Daniel > --=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 :|