From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ITD33-0005we-1B for qemu-devel@nongnu.org; Thu, 06 Sep 2007 04:49:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ITD31-0005vv-31 for qemu-devel@nongnu.org; Thu, 06 Sep 2007 04:49:12 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ITD30-0005vp-SR for qemu-devel@nongnu.org; Thu, 06 Sep 2007 04:49:10 -0400 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ITD30-0003mS-BV for qemu-devel@nongnu.org; Thu, 06 Sep 2007 04:49:10 -0400 Message-ID: <46DFBE4F.5080206@qumranet.com> Date: Thu, 06 Sep 2007 11:46:07 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [kvm-devel] expose host CPU features to guests References: <20070905174530.GA3945@karma.qumranet.com> <46DF04D5.5000807@qumranet.com> <20070905194448.GN5503@redhat.com> <200709060130.03618.paul@codesourcery.com> In-Reply-To: <200709060130.03618.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: kvm-devel , qemu-devel@nongnu.org Paul Brook wrote: >>> I think qemu-cvs has a -cpu option for non-x86 which could be used for >>> this. Agree machine types are the wrong approach. >>> >> Yep, machine types are already used to switch between a different concept >> so using the new -cpu option would make sense. Could perhaps extend the >> syntax so that instead of '-cpu TYPE' it used '-cpu TYPE,FEATURES' where >> FEATURES was an optional list of CPU features to allow >> > > I tried this for ARM, and having separate type+features isn't worth the > effort. The internal implementation is feature based, but IMHO there's little > benefit exposing that to the user. Just define appropriate CPUs for the > interesting feature combinations. > > The use case is different. We don't care about the actual features, but about finding the greatest common denominator in a virtualization farm. I don't see this as useful for qemu; rather kvm and kqemu. > Of course the x86 emulation doesn't currently support restricting the > architecture features available. To make the --cpu option useful you need to > implement that first. > Applications will not use a feature that is not present in cpuid, so that is not an issue. For the virtualization use case, it is also impossible to turn off support for a feature. -- Any sufficiently difficult bug is indistinguishable from a feature.