From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RRr-0008Jw-Kx for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:53:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7RRn-00043M-1z for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:53:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RRm-00043E-Qf for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:53:18 -0400 Date: Tue, 23 Jun 2015 17:53:13 +0100 From: "Daniel P. Berrange" Message-ID: <20150623165313.GN30318@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> <55898BF3.9050107@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55898BF3.9050107@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 Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= 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, Eduardo Habkost On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas F=C3=A4rber wrote: > Am 23.06.2015 um 18:25 schrieb Daniel P. Berrange: > > 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 > This coupling is by design and we expect all KVM/QEMU users to adhere t= o > it, including those that use the libvirt tool (which I assume is going > to be the majority of KVM users). Either you want a certain > backwards-compatible machine and CPU, or you want the latest and > greatest - why in the world mix and match?! As mentioned, changes/fixes to the CPU model can affect the ability to launch the guest on a particular host, so we need the ability to control when those CPU changes are activated for a guest, separately from the machine type. > Would a qemu64-2.3 model help here that pc*-2.3 could use? I believe > that's been proposed in the past. I don't oppose the idea of a > fully-custom CPU, but this blatant attempt of ignoring QEMU's CPU > versioning by libvirt worries me. That is still tieing CPU model names to machine type versions, unless I'm mis-understanding you. In general having QEMU models avialable vary depending on the QEMU version is creating problems for apps higher up the stack. By allowing libvirt to define the CPU model policy, it can also provide a more consistent interface to applications above, such as OpenStack, which will facilitate work in the schedular when it picks hosts capable of deploying/migrating a VM, when there are heterogenous QEMU versions across the hosts. 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 :|