From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZKvJ-0001w0-AB for qemu-devel@nongnu.org; Mon, 25 Jan 2010 04:07:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZKvE-0001pi-Lu for qemu-devel@nongnu.org; Mon, 25 Jan 2010 04:07:52 -0500 Received: from [199.232.76.173] (port=47813 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZKvE-0001pP-Fr for qemu-devel@nongnu.org; Mon, 25 Jan 2010 04:07:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52071) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZKvD-0001vX-MD for qemu-devel@nongnu.org; Mon, 25 Jan 2010 04:07:48 -0500 Message-ID: <4B5D5F84.4040507@redhat.com> Date: Mon, 25 Jan 2010 11:08:20 +0200 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. References: <4B549016.6090501@redhat.com> <4B560A88.9@codemonkey.ws> <20100119200349.GG3204@sequoia.sous-sol.org> <4B563144.9030803@codemonkey.ws> <4B576311.3030906@redhat.com> <20100120202634.GA20754@redhat.com> <20100121002509.GM3204@sequoia.sous-sol.org> <4B57AB66.30802@redhat.com> <4B586D4A.50207@codemonkey.ws> In-Reply-To: <4B586D4A.50207@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Przywara, Andre" , KVM list , john cooper , qemu-devel@nongnu.org, Chris Wright , Gerd Hoffmann On 01/21/2010 05:05 PM, Anthony Liguori wrote: > On 01/20/2010 07:18 PM, john cooper wrote: >> Chris Wright wrote: >>> * Daniel P. Berrange (berrange@redhat.com) wrote: >>>> To be honest all possible naming schemes for '-cpu' are just as >>>> unfriendly as each other. The only user friendly option is '-cpu host'. >>>> >>>> IMHO, we should just pick a concise naming scheme& document it. Given >>>> they are all equally unfriendly, the one that has consistency with >>>> vmware >>>> naming seems like a mild winner. >>> Heh, I completely agree, and was just saying the same thing to John >>> earlier today. May as well be -cpu {foo,bar,baz} since the meaning for >>> those command line options must be well-documented in the man page. >> I can appreciate the concern of wanting to get this >> as "correct" as possible. > > This is the root of the trouble. At the qemu layer, we try to focus on > being correct. > > Management tools are typically the layer that deals with being "correct". > > A good compromise is making things user tunable which means that a > downstream can make "correctness" decisions without forcing those > decisions on upstream. > > In this case, the idea would be to introduce a new option, say something > like -cpu-def. The syntax would be: > > -cpu-def > name=coreduo,level=10,family=6,model=14,stepping=8,features=+vme+mtrr+clflush+mca+sse3+monitor,xlevel=0x80000008,model_id="Genuine > Intel(R) CPU T2600 @ 2.16GHz" > > Which is not that exciting since it just lets you do -cpu coreduo in a > much more complex way. However, if we take advantage of the current > config support, you can have: > > [cpu-def] > name=coreduo > level=10 > family=6 > model=14 > stepping=8 > features="+vme+mtrr+clflush+mca+sse3.." > model_id="Genuine Intel..." > > And that can be stored in a config file. We should then parse > /etc/qemu/target-.conf by default. We'll move the current > x86_defs table into this config file and then downstreams/users can > define whatever compatibility classes they want. > > With this feature, I'd be inclined to take "correct" compatibility > classes like Nehalem as part of the default qemurc that we install > because it's easily overridden by a user. It then becomes just a > suggestion on our part verses a guarantee. > > It should just be a matter of adding qemu_cpudefs_opts to > qemu-config.[ch], taking a new command line that parses the argument via > QemuOpts, then passing the parsed options to a target-specific function > that then builds the table of supported cpus. Isn't the outcome of John's patches and these configs will be exactly the same? Since these cpu models won't ever change, there is no reason why not to hard code them. Adding configs or command lines is a good idea but it is more friendlier to have basic support to the common cpus. This is why qemu today offers: -cpu ? x86 qemu64 x86 phenom x86 core2duo x86 kvm64 x86 qemu32 x86 coreduo x86 486 x86 pentium x86 pentium2 x86 pentium3 x86 athlon x86 n270 So bottom line, my point is to have John's base + your configs. We need to keep also the check verb and the migration support for sending those. btw: IMO we should deal with this complexity ourselves and save 99.9% of the users the need to define such models, don't ask this from a java programmer, he is running on a JVM :-) > > Regards, > > Anthony Liguori > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html