From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9e7M-0005AN-PU for qemu-devel@nongnu.org; Tue, 12 Apr 2011 09:58:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9e7L-0001vB-Jo for qemu-devel@nongnu.org; Tue, 12 Apr 2011 09:58:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9e7L-0001uu-4F for qemu-devel@nongnu.org; Tue, 12 Apr 2011 09:58:55 -0400 Message-ID: <4DA45A7E.40408@redhat.com> Date: Tue, 12 Apr 2011 15:58:22 +0200 From: Jes Sorensen MIME-Version: 1.0 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> <4D99DB87.2040606@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Peter Maydell , qemu-devel@nongnu.org, patches@linaro.org On 04/04/11 18:54, Blue Swirl wrote: > On Mon, Apr 4, 2011 at 5:53 PM, Jes Sorensen wrote: >> 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. > > We could have "-device RAM,base=xxx,size=yyy,id=DIMM1 -numa > nodeid=zzz,memory=DIMM1" for fine tuned control. > > But asking users to list and bind the DIMMs needed just to have some > amount of RAM is a bit too much. So we also need a simple case (-m) > and a simple check for the max memory. I totally agree, but the suggestion I proposed earlier doesn't in any way prevent this. If we use a table of valid memory locations for a given board, then it is really easy for each board to provide a validation function which accepts the amount or rejects 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. > > Maybe we could remove some of memory logic in pc.c with this approach. I believe it would simplify things a great deal, and have the benefit that we can emulate things much more realistically. The only issue is that it takes a little more work up front, but it really isn't a big deal. Cheers, Jes