From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38080 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1ksQ-0000ZK-Mi for qemu-devel@nongnu.org; Mon, 21 Mar 2011 15:35:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1krx-0003SL-3V for qemu-devel@nongnu.org; Mon, 21 Mar 2011 15:34:26 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:53981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1krw-0003S5-WD for qemu-devel@nongnu.org; Mon, 21 Mar 2011 15:34:25 -0400 Received: by ywl41 with SMTP id 41so3153381ywl.4 for ; Mon, 21 Mar 2011 12:34:24 -0700 (PDT) Message-ID: <4D87A83B.1060009@codemonkey.ws> Date: Mon, 21 Mar 2011 14:34:19 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct References: <1300729640-6410-1-git-send-email-peter.maydell@linaro.org> In-Reply-To: <1300729640-6410-1-git-send-email-peter.maydell@linaro.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: David Gibson , qemu-devel@nongnu.org, patches@linaro.org On 03/21/2011 12:47 PM, Peter Maydell wrote: > This fairly simple patchset adds 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 advantage of doing this in vl.c rather than in each board (apart > from avoiding code duplication) is that we can distinguish between > "the user asked for more RAM than we support" (an error) and "the global > default RAM size is more than our maximum" (just cap the RAM size to > the board maximum). > > I did think about also adding a "default_ram" field so each board could > default to the same amount of RAM that real hardware has, but since we > allocate RAM up front rather than only when accessed, this would push the > initial default allocated RAM size up from 128MB to 1GB on models like > the PBX A9, and it didn't seem very friendly to do that. I'm happy > to be persuaded back again, though :-) I don't have any objections to these patches, but it makes me wonder if we should try to go further. There are certainly a lot of use-cases where the boards being emulated are extremely sensitive to the options specified. I wonder if we ought to provide a better way for boards to participate in command line validation. For instance, I know that many boards can only accept certain RAM sizes that map to realistic DIMM sizes. I don't have any great ideas here but wonder if it's something we should more seriously consider. Regards, Anthony Liguori > This patchset was prompted by bugs like: > https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/584480 > https://bugs.launchpad.net/ubuntu/+source/rootstock/+bug/570588 > > Peter Maydell (2): > Allow boards to specify maximum RAM size > hw: Add maximum RAM specifications for ARM devboard models > > hw/boards.h | 1 + > hw/integratorcp.c | 1 + > hw/realview.c | 11 +++++++++++ > hw/versatilepb.c | 5 +++++ > vl.c | 16 +++++++++++++++- > 5 files changed, 33 insertions(+), 1 deletions(-) > >