From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40342 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6lAv-000798-C0 for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:56:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q6lAi-0007wK-NE for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:54:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q6lAi-0007wE-DN for qemu-devel@nongnu.org; Mon, 04 Apr 2011 10:54:28 -0400 Message-ID: <4D99DB87.2040606@redhat.com> Date: Mon, 04 Apr 2011 16:53:59 +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> <4D99D5BA.3010403@redhat.com> 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 04/04/11 16:42, Peter Maydell wrote: > On 4 April 2011 15:29, Jes Sorensen wrote: >>> 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? > > For the boards I care about (the ARM ones), the only validation > requirement is that we don't allow the user to specify so much > ram that we overlap physical RAM with I/O space. So ram_size is > good enough. For the sun4m boards we can assume that the only > validation they need is a ram_size check, because that's all they > do at the moment and nobody's complaining that I know of. I understand that what you are proposing seems to work well enough for your problem at hand. What I am saying is that adding a mechanism like that, can cause problems for adding a more generic mechanism that handles more advanced boards in the future. I much prefer a generic solution than a simple hack. >> 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? > > If you have a concrete example of multiple boards which we currently model > and which require this level of flexibility to avoid odd misbehaviour trying > to run a guest, then please point them out and I'll look at expanding the > patch to cover their requirements. > > If this is just a theoretical issue, then I think we should only add the > extra generic framework code if and when we turn out to need it. As I pointed out before, this is not a theoretical problem, most numa systems have this issue, including many x86 boxes. I can see the problem also existing with mips boards like the sb1250 ones I worked on many years ago. Having an a table of valid ram locations for a board, will also give you a framework to validate against if you want to be able to specify chunks of memory at different areas of a board. This could be useful for testing behavior that is like it would be if you have a system where installing different DIMMs would split the RAM up differently. Jes