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: Tue, 12 Apr 2011 15:55:29 +0200 [thread overview]
Message-ID: <4DA459D1.1030407@redhat.com> (raw)
In-Reply-To: <BANLkTinH_Pv0FsO7=JPPd=-5ZLiXGe9Mug@mail.gmail.com>
On 04/04/11 19:26, Peter Maydell wrote:
> On 4 April 2011 15:53, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> I understand that what you are proposing seems to work well enough for
>> your problem at hand. What I am saying is that adding a mechanism like
>> that, can cause problems for adding a more generic mechanism that
>> handles more advanced boards in the future. I much prefer a generic
>> solution than a simple hack.
>
> I don't think it's a hack. I think it's a reasonably clean solution
> to the set of cases we've actually encountered in practice, and I
> think trying to design something more generalised without actually
> having a use case to tie it to is just going to produce something
> complicated which doesn't turn out to actually be what a hypothetical
> "advanced board" will actually need. I think we're much better off
> with code that does what we need it to do now, and designing
> and implementing the complicated generic framework only when we
> actually need it.
Sorry but it is not a clean solution at all, it's a simple hack based on
a linear model, which happens to work in practice when dealing with some
simple boards. I suggested a very simple interface that would work fine
for embedded boards, and which would be simple to implement.
The so called advanced boards you're referring to are out there in
numbers already, you probably have a couple of them. They are called PCs.
>> As I pointed out before, this is not a theoretical problem, most numa
>> systems have this issue, including many x86 boxes. I can see the problem
>> also existing with mips boards like the sb1250 ones I worked on many
>> years ago.
>
> OK, so presumably you can provide a qemu command line and an image
> which demonstrates the problem...
Look at the -numa argument and show me the code that actually validates
the memory amount correctly in that case?
Jes
prev parent reply other threads:[~2011-04-12 13:56 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
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 [this message]
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=4DA459D1.1030407@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).