[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMU
Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
Mon, 21 Mar 2011 14:34:19 -0500
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
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.
This patchset was prompted by bugs like:
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(-)