From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= Subject: Re: [Qemu-devel] [PATCH v2 1/3] KVM: Add new -cpu best Date: Mon, 02 Jul 2012 16:24:26 +0200 Message-ID: <4FF1AF1A.9080107@suse.de> References: <1340728795-4379-1-git-send-email-agraf@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: qemu-devel qemu-devel , Anthony Liguori , Ryan Harper , Avi Kivity , KVM list To: Alexander Graf Return-path: Received: from cantor2.suse.de ([195.135.220.15]:44253 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753894Ab2GBOYa (ORCPT ); Mon, 2 Jul 2012 10:24:30 -0400 In-Reply-To: <1340728795-4379-1-git-send-email-agraf@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Am 26.06.2012 18:39, schrieb Alexander Graf: > During discussions on whether to make -cpu host the default in SLE, I= found s/make -cpu host the default/support/? > myself disagreeing to the thought, because it potentially opens a big= can > of worms for potential bugs. But if I already am so opposed to it for= SLE, how > can it possibly be reasonable to default to -cpu host in upstream QEM= U? And > what would a sane default look like? >=20 > So I had this idea of looping through all available CPU definitions. = We can > pretty well tell if our host is able to execute any of them by checki= ng the > respective flags and seeing if our host has all features the CPU defi= nition > requires. With that, we can create a -cpu type that would fall back t= o the > "best known CPU definition" that our host can fulfill. On my Phenom I= I > system for example, that would be -cpu phenom. >=20 > With this approach we can test and verify that CPU types actually wor= k at > any random user setup, because we can always verify that all the -cpu= types > we ship actually work. And we only default to some clever mechanism t= hat > chooses from one of these. >=20 > Signed-off-by: Alexander Graf Despite the long commit message a cover letter would've been nice. ;) Anything that operates on x86_def_t will obviously need to be refactore= d when we agree on the course for x86 CPU subclasses. But no objection to getting it done some way that works today. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlhYK-0008Ij-Ih for qemu-devel@nongnu.org; Mon, 02 Jul 2012 10:24:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SlhYF-00016Z-63 for qemu-devel@nongnu.org; Mon, 02 Jul 2012 10:24:36 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44252 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlhYE-00016K-Su for qemu-devel@nongnu.org; Mon, 02 Jul 2012 10:24:31 -0400 Message-ID: <4FF1AF1A.9080107@suse.de> Date: Mon, 02 Jul 2012 16:24:26 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1340728795-4379-1-git-send-email-agraf@suse.de> In-Reply-To: <1340728795-4379-1-git-send-email-agraf@suse.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 1/3] KVM: Add new -cpu best List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: KVM list , Ryan Harper , qemu-devel qemu-devel , Anthony Liguori , Avi Kivity Am 26.06.2012 18:39, schrieb Alexander Graf: > During discussions on whether to make -cpu host the default in SLE, I f= ound s/make -cpu host the default/support/? > myself disagreeing to the thought, because it potentially opens a big c= an > of worms for potential bugs. But if I already am so opposed to it for S= LE, how > can it possibly be reasonable to default to -cpu host in upstream QEMU?= And > what would a sane default look like? >=20 > So I had this idea of looping through all available CPU definitions. We= can > pretty well tell if our host is able to execute any of them by checking= the > respective flags and seeing if our host has all features the CPU defini= tion > requires. With that, we can create a -cpu type that would fall back to = the > "best known CPU definition" that our host can fulfill. On my Phenom II > system for example, that would be -cpu phenom. >=20 > With this approach we can test and verify that CPU types actually work = at > any random user setup, because we can always verify that all the -cpu t= ypes > we ship actually work. And we only default to some clever mechanism tha= t > chooses from one of these. >=20 > Signed-off-by: Alexander Graf Despite the long commit message a cover letter would've been nice. ;) Anything that operates on x86_def_t will obviously need to be refactored when we agree on the course for x86 CPU subclasses. But no objection to getting it done some way that works today. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg