From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RJm-0003Gx-4n for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:45:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7RJi-0008CM-K7 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:45:02 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37360 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RJi-0008BW-Dr for qemu-devel@nongnu.org; Tue, 23 Jun 2015 12:44:58 -0400 Message-ID: <55898D09.2060405@suse.de> Date: Tue, 23 Jun 2015 18:44:57 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= 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> <20150623183115-mutt-send-email-mst@redhat.com> <20150623163858.GG3134@thinpad.lan.raisama.net> In-Reply-To: <20150623163858.GG3134@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 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: Eduardo Habkost 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 Am 23.06.2015 um 18:38 schrieb Eduardo Habkost: > On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote: >> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote: >>> 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. >> >> But that's because we are fixing bugs. If CPU X used to work on >> hardware Y in machine type A and stopped in machine type B, this is >> because we have determined that it's the right thing to do for the >> guests and the users. We don't break stuff just for fun. >> Why do you want to bring back the bugs we fixed? >=20 > I didn't take the time to count them, but I bet most of the commits I > listed on my previous e-mail message are not bug fixes, but new > features. Huh? Of course the latest machine model get new features. The point is that the previous ones don't and that's what we are providing them for - libvirt is expected to choose one machine and the contract with QEMU is that for that machine the CPU does *not* grow new features, and we're going at great lengths to achieve that. So this thread feels more and more weird... Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)