Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/30/2011 08:22 AM, Peter Maydell wrote:
> On 30 March 2011 11:51, Jes Sorensen<Jes.Sorensen@redhat.com>  wrote:
>> 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.
> 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
>