From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43003 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q6nY5-0003h4-UY for qemu-devel@nongnu.org; Mon, 04 Apr 2011 13:26:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q6nY4-0004mX-CK for qemu-devel@nongnu.org; Mon, 04 Apr 2011 13:26:45 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:37733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q6nY4-0004mJ-A3 for qemu-devel@nongnu.org; Mon, 04 Apr 2011 13:26:44 -0400 Received: by vws17 with SMTP id 17so4985598vws.4 for ; Mon, 04 Apr 2011 10:26:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4D99DB87.2040606@redhat.com> 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> Date: Mon, 4 Apr 2011 18:26:43 +0100 Message-ID: Subject: Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct From: Peter Maydell Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: Blue Swirl , qemu-devel@nongnu.org, patches@linaro.org On 4 April 2011 15:53, 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. I don't think it's a hack. I think it's a reasonably clean solution to the set of cases we've actually encountered in practice, and I think trying to design something more generalised without actually having a use case to tie it to is just going to produce something complicated which doesn't turn out to actually be what a hypothetical "advanced board" will actually need. I think we're much better off with code that does what we need it to do now, and designing and implementing the complicated generic framework only when we actually need it. >> 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. OK, so presumably you can provide a qemu command line and an image which demonstrates the problem... > Having an a table of valid ram locations for a board ...I'm not sure this is even meaningful for boards where you can remap the RAM to different physical addresses at runtime (versatile express ought to do this although we don't currently model that bit). -- PMM