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: Wed, 30 Mar 2011 12:51:22 +0200 [thread overview]
Message-ID: <4D930B2A.4080808@redhat.com> (raw)
In-Reply-To: <AANLkTi=HUJUTGJbfbzfYnkjj=fy_LGjVK_Ehfb7MDC2D@mail.gmail.com>
On 03/30/11 10:09, Peter Maydell wrote:
> On 30 March 2011 08:48, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> I am a little concerned about this approach. It should work for simple
>> embedded boards, but for larger systems, it really ought to be a mask
>> rather than a max address.
>
> It's not a maximum address, it's a maximum size. For instance
> the RAM isn't contiguous on some of the ARM devboards.
Right, but the fact that you can have holes makes it even more an issue.
>> Ideally I think it would be better to have a mask and then introduce a
>> is_valid_memory() kinda function to check it with.
>
> The command line option doesn't provide any means of saying
> "put 64MB in this hole and another 128 over here and 32 there",
> so this seems completely pointless to me. All we are trying
> to do is validate what the user has asked for, so why have
> a validation mechanism that can cope with impossible-to-request
> arrangements?
You can on x86 using the -numa argument. When you use that, it is
completely pointless to have the max memory limit, to use your own words.
>> I fear that by introducing a simple max limit like this, we are going to
>> hit problems later when we try to improve the NUMA support.
>
> I think this is letting the best be the enemy of the good.
>
> Even if you do want to have NUMA systems do more complex
> things I think you should still have the simple "maximum
> size" approach for the bulk of the supported boards which
> don't need anything more complicated. So additional NUMA
> features would augment, not replace this.
The problem is we end up with two mechanisms that way which won't
necessarily live well together.
Since you have holes on ARM too, it makes sense IMHO to use a mask
exactly because you can then map that to max memory by simply adding up
the available holes. A linear number on the other hand is much harder to
validate against once you start populating holes explicitly.
Cheers,
Jes
next prev parent reply other threads:[~2011-03-30 10:51 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 [this message]
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
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=4D930B2A.4080808@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).