From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM usability Date: Tue, 09 Mar 2010 19:11:49 +0200 Message-ID: <4B968155.5030300@redhat.com> References: <1267068445.1726.25.camel@localhost> <1267089644.12790.74.camel@laptop> <1267152599.1726.76.camel@localhost> <20100226090147.GH15885@elte.hu> <4B879A2F.50203@redhat.com> <20100226103545.GA7463@elte.hu> <4B87A6BF.3090301@redhat.com> <20100226111734.GE7463@elte.hu> <4B8813F2.8090208@redhat.com> <20100227105643.GA17425@elte.hu> <4B8C38B8.8010007@codemonkey.ws> <62EE499D-BE5D-4014-80C7-6FB3A0A1C71E@suse.de> <4B8C799A.6000102@codemonkey.ws> <4B964DD0.4090100@redhat.com> <1268145178.2251.12.camel@x200> <6CF4AA9A-5C83-42C2-80BF-AEEFE68A99B6@suse.de> <4B96602D.8050604@codemonkey.ws> <4B9660C6.4080405@redhat.com> <4B9661D1.8040109@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , kirkland@canonical.com, Ingo Molnar , "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Zachary Amsden , Gleb Natapov , Arnaldo Carvalho de Melo , Fr??d??ric Weisbecker , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Arjan van de Ven To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37359 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751366Ab0CIRMq (ORCPT ); Tue, 9 Mar 2010 12:12:46 -0500 In-Reply-To: <4B9661D1.8040109@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 03/09/2010 04:57 PM, Anthony Liguori wrote: > On 03/09/2010 08:52 AM, Avi Kivity wrote: >> On 03/09/2010 04:50 PM, Anthony Liguori wrote: >>>> It's all in the openSUSE build service. The direct access URL >>>> (login required FWIW) is here: >>>> >>>> https://build.opensuse.org/package/view_file?file=kvm-qemu-default-memsize.patch&package=kvm&project=Virtualization >>>> >>>> >>>> It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the >>>> "kvm" package. >>> >>> We should attempt to do three things with default ram size: >>> >>> 1) bump it up to a more reasonable number >>> 2) make it specified in the global default config >>> 3) make sure we can provide compatibility support for older machine >>> types >> >> It's really sad, the amount of code needed to change a number. > > We don't do enough via a config. If we did, we could just have a 0.12 > config version that got frozen over time. > > So really, if we can make the mem readable by global config, and we > can have machine specific configs, it would simplify the problem in > the future so that we just had to bump a number. Perhaps a json representation of things. We already have the parser. -- error compiling committee.c: too many arguments to function