qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Blue Swirl <blauwirbel@gmail.com>,
	qemu-devel@nongnu.org, patches@linaro.org
Subject: Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
Date: Mon, 04 Apr 2011 16:29:14 +0200	[thread overview]
Message-ID: <4D99D5BA.3010403@redhat.com> (raw)
In-Reply-To: <AANLkTimzP3x3eUkY5QUNZKLO5+S_qWKA+7UdPmyfhA0V@mail.gmail.com>

On 03/30/11 16:07, Peter Maydell wrote:
> On 30 March 2011 14:56, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> On 03/30/2011 08:22 AM, Peter Maydell wrote:
>>> Not really, typically they're just filled up in some particular
>>> order (main RAM in one place and expansion RAM elsewhere).
>>> Since the board init function is only passed a single "ram_size"
>>> parameter that's all you can do anyhow.
>>
>> FWIW, I don't think any static data is going to be perfect here.  A lot of
>> boards have strict requirements on ram_size based on plausible combinations
>> of DIMMs.  Arbitrary values up to ram_size is not good enough.
>>
>> ram_size ought to be viewed as a hint, not a mechanism to allow common code
>> to completely validate the passed in ram size parameter.  It's still up to
>> the board to validate that the given ram size makes sense.
> 
> Yes, I agree, so we shouldn't try to specify some complicated
> set of static data that still won't be good enough.
> 
> I'm trying to make it easy for boards to avoid crashing horribly
> when the user passes a bad value; that's all.

If you don't validate properly, is there really a point in introducing
that value anyway? From what you write, it sounds like it can still fail
for some limits of the memory valid if the config is wrong?

It still seems to me it would be better to have the boards present a
table of valid memory ranges so we can do a proper validation of the valud?

Cheers,
Jes

  reply	other threads:[~2011-04-04 14:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-29 14:08 [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 1/7] Allow boards to specify maximum RAM size Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 2/7] hw: Add maximum RAM specifications for ARM devboard models Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 3/7] vl.c: Fix machine registration so QEMUMachine structs can be const Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 4/7] hw/sun4m: Move QEMUMachine structs into sun4*_hwdef structs Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 5/7] hw/sun4m: Use the QEMUMachine max_ram to implement memory limit Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 6/7] hw/sun4m: Use a macro to hide the repetitive board init functions Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 7/7] hw: Make QEMUMachine structure definitions const Peter Maydell
2011-03-30  7:48 ` [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Jes Sorensen
2011-03-30  8:09   ` Peter Maydell
2011-03-30 10:51     ` Jes Sorensen
2011-03-30 13:22       ` Peter Maydell
2011-03-30 13:55         ` Jes Sorensen
2011-03-30 13:56         ` Anthony Liguori
2011-03-30 14:07           ` Peter Maydell
2011-04-04 14:29             ` Jes Sorensen [this message]
2011-04-04 14:42               ` Peter Maydell
2011-04-04 14:53                 ` Jes Sorensen
2011-04-04 16:54                   ` Blue Swirl
2011-04-12 13:58                     ` Jes Sorensen
2011-04-04 17:26                   ` Peter Maydell
2011-04-12 13:55                     ` Jes Sorensen

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=4D99D5BA.3010403@redhat.com \
    --to=jes.sorensen@redhat.com \
    --cc=blauwirbel@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).