On 03/30/2011 08:22 AM, Peter Maydell wrote:
On 30 March 2011 11:51, Jes Sorensen<jes.soren...@redhat.com> wrote:
On 03/30/11 10:09, Peter Maydell wrote:
On 30 March 2011 08:48, Jes Sorensen<jes.soren...@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.
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.
Regards,
Anthony Liguori
Ideally I think it would be better to have a mask and then introduce a
is_valid_memory() kinda function to check it with.
I'm not sure what this mask would look like. You want megabyte
granularity, but even if you assume only 48 bit physical addresses
that would still be an alarmingly large number of bits. So I
guess you'd actually want a list of (start,length) tuples.
I strongly dislike this approach. I think it introduces unneeded
extra complexity, and it doesn't even address all the cases you
might want a generic "validate RAM options" mechanism to do (eg
boards which only allow RAM in 16MB increments, boards where you
must fill the base RAM first and then the expansion RAM, boards
where the RAM isn't at a specific physical address but can be
remapped under guest control, just to pick three). So it falls
awkwardly between the two stools of "flexible and generic" and
"simple and straightforward".
The command line option doesn't provide any means of saying
"put 64MB in this hole and another 128 over here and 32 there",
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.
(Is there any documentation on what you can do with the -numa
option? http://qemu.weilnetz.de/qemu-doc.html is decidedly laconic.)
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.
But I don't want to populate holes explicitly, and I don't imagine
most of the other boards want to populate holes explicitly
either.
The current QEMU design basically only controls the total amount
of RAM (as a command line option, and as a parameter to the board
init function), with NUMA being a an optional extra. Non-NUMA is
the common use case and you want the API used by the board code
to be straightforward to implement this common case. Adding a
simple "maximum RAM" field fits in with the existing design and
solves a genuine requirement for multiple board models.
Even if one system happens to have NUMA-specific requirements we
don't want to have to have every single devboard specify its RAM
limits in a complicated fashion for the benefit of the one NUMA
system. Just have the NUMA system not specify max_ram (so it gets
the default of zero, ie "don't check") and have some NUMA-specific
QEMUMachine fields which default to "system doesn't support NUMA".
Then NUMA aware board models can do the right thing, and non-NUMA
boards also do the right thing without having to think about
NUMA-related fields at all.
(Compare the way non-SMP boards don't have to worry about the
max_cpus field.)
-- PMM
