From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7PoS-0007NX-1a for qemu-devel@nongnu.org; Tue, 23 Jun 2015 11:08:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7PoN-0007c9-V3 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 11:08:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7PoN-0007ae-Pn for qemu-devel@nongnu.org; Tue, 23 Jun 2015 11:08:31 -0400 Date: Tue, 23 Jun 2015 12:08:28 -0300 From: Eduardo Habkost Message-ID: <20150623150828.GD3134@thinpad.lan.raisama.net> References: <1433790460-30679-1-git-send-email-ehabkost@redhat.com> <20150608201835.GM3525@orkuz.home> <558951C0.3050806@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <558951C0.3050806@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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= 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 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 script is pr= ovided, > >> that will generate a config file that can be loaded using -readconfi= g, 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 makes sens= e. > > We already have a partial copy of CPU model definitions in libvirt > > anyway, but as QEMU changes some CPU models in some machine types (an= d > > libvirt does not do that) we have no real control over the guest CPU > > configuration. While what we really want is full control to enforce > > stable guest ABI. >=20 > That sounds like FUD to me. Any concrete data points where QEMU does no= t > have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machine= s > 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 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 models 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 Eduardo