All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: David Gibson <david@gibson.dropbear.id.au>,
	qemu-devel@nongnu.org, patches@linaro.org
Subject: Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
Date: Mon, 21 Mar 2011 14:34:19 -0500	[thread overview]
Message-ID: <4D87A83B.1060009@codemonkey.ws> (raw)
In-Reply-To: <1300729640-6410-1-git-send-email-peter.maydell@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(-)
>
>

  parent reply	other threads:[~2011-03-21 19:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-21 17:47 [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
2011-03-21 17:47 ` [Qemu-devel] [PATCH 1/2] Allow boards to specify maximum RAM size Peter Maydell
2011-03-21 17:47 ` [Qemu-devel] [PATCH 2/2] hw: Add maximum RAM specifications for ARM devboard models Peter Maydell
2011-03-21 19:34 ` Anthony Liguori [this message]
2011-03-21 20:44 ` [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct Brad Hards
2011-03-26 11:41 ` Blue Swirl
2011-03-28 10:32   ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D87A83B.1060009@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=david@gibson.dropbear.id.au \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.