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