From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RFK-0006pE-9z for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:40:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7RFG-0006MV-4A for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:40:26 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37087 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RFF-0006M5-NL for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:40:21 -0400 Message-ID: <55898BF3.9050107@suse.de> Date: Tue, 23 Jun 2015 18:40:19 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 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> In-Reply-To: <20150623162555.GL30318@redhat.com> Content-Type: text/plain; charset=utf-8 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, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , rth@twiddle.net, Eduardo Habkost 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 situation > because we want to be able to be able to access different versions of > the CPU without the machine type changing, and access different version= s > of the machine type, without the CPU changing. IOW it is the fact that = the > changes in CPU are tied to changes in machine type that is the core > problem. This coupling is by design and we expect all KVM/QEMU users to adhere to 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?! 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. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; = HRB 21284 (AG N=C3=BCrnberg)