From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53154 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6kmp-0000y6-40 for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:29:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q6kml-0002N2-8S for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:29:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q6kmk-0002MG-W3 for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:29:43 -0400 Message-ID: <4D99D5BA.3010403@redhat.com> Date: Mon, 04 Apr 2011 16:29:14 +0200 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct References: <1301407704-24541-1-git-send-email-peter.maydell@linaro.org> <4D92E057.4010005@redhat.com> <4D930B2A.4080808@redhat.com> <4D933677.8000606@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Blue Swirl , qemu-devel@nongnu.org, patches@linaro.org On 03/30/11 16:07, Peter Maydell wrote: > On 30 March 2011 14:56, Anthony Liguori wrote: >> On 03/30/2011 08:22 AM, Peter Maydell wrote: >>> Not really, typically they're just filled up in some particular >>> order (main RAM in one place and expansion RAM elsewhere). >>> Since the board init function is only passed a single "ram_size" >>> parameter that's all you can do anyhow. >> >> FWIW, I don't think any static data is going to be perfect here. A lot of >> boards have strict requirements on ram_size based on plausible combinations >> of DIMMs. Arbitrary values up to ram_size is not good enough. >> >> ram_size ought to be viewed as a hint, not a mechanism to allow common code >> to completely validate the passed in ram size parameter. It's still up to >> the board to validate that the given ram size makes sense. > > Yes, I agree, so we shouldn't try to specify some complicated > set of static data that still won't be good enough. > > I'm trying to make it easy for boards to avoid crashing horribly > when the user passes a bad value; that's all. If you don't validate properly, is there really a point in introducing that value anyway? From what you write, it sounds like it can still fail for some limits of the memory valid if the config is wrong? It still seems to me it would be better to have the boards present a table of valid memory ranges so we can do a proper validation of the valud? Cheers, Jes