From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36069 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4q9N-0002yv-BX for qemu-devel@nongnu.org; Wed, 30 Mar 2011 03:49:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4q9K-0004pn-5W for qemu-devel@nongnu.org; Wed, 30 Mar 2011 03:49:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4q9J-0004ph-Qq for qemu-devel@nongnu.org; Wed, 30 Mar 2011 03:49:06 -0400 Message-ID: <4D92E057.4010005@redhat.com> Date: Wed, 30 Mar 2011 09:48:39 +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> In-Reply-To: <1301407704-24541-1-git-send-email-peter.maydell@linaro.org> Content-Type: text/plain; charset=ISO-8859-1 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/29/11 16:08, Peter Maydell wrote: > This primary aim of this patchset is to add a new 'max_ram' field to the > QEMUMachine structure so that a board model can specify the maximum RAM it > will accept. We can then produce a friendly diagnostic message when the > user tries to start qemu with a '-m' option asking for more RAM than that. > (Currently most of the ARM devboard models respond with an obscure guest > crash when the guest tries to access RAM and finds device registers > instead.) > > If no maximum size is specified we default to the old behaviour of > "do not impose any limit". > > The bulk of the patchset is knock-on cleanup as a result, in particular > allowing QEMUMachine structs to be const and sun4m cleanup. Hi Peter, Sorry for not getting to this patch earlier. I am a little concerned about this approach. It should work for simple embedded boards, but for larger systems, it really ought to be a mask rather than a max address. On NUMA systems you are bound to have holes, and at times you might not even start from address 0. In these cases you are likely to have device registers mapped in between the memory chunks. Ideally I think it would be better to have a mask and then introduce a is_valid_memory() kinda function to check it with. I fear that by introducing a simple max limit like this, we are going to hit problems later when we try to improve the NUMA support. Cheers, Jes