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

[Jes Sorensen]

On 03/30/11 15:22, Peter Maydell wrote:
> On 30 March 2011 11:51, Jes Sorensen <address@hidden>
> wrote:
>>>> 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".

I thought about it a bit and obviously a simple mask isn't going to cut
it. What we should have is more like a list of valid ram locations which
we can use to calculate the allowable size for. The -m parameter is
really a shortcut for the real thing, and we shouldn't optimize for -m,
but rather the other way round.


>> 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.)

I don't know of documentation for that unfortunately :( Eventually you
should be able to do anything with it that can happen in a real numa
system. Basically it should allow you to define nodes and assign CPUs
and memory to the given nodes, as well as PCI devices.

>> 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.

Why not? You just mentioned the case where board holes can be populated
in different ways?

> 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.

The problem with the existing design is exactly that it was designed for
the simple case, and works badly for the case that matches the hardware
better. I suggest we do it right, and then provide functions to make -m
work easily. Otherwise we end up with bad hacks that are going to work
badly for the non simple case.

> 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.)

A simple system is basically a single-node NUMA system. So you refer to
NODE 0 per default if no explicit node is listed. Instead what we should
have is something like this

struct node_memregion {
        uint64_t start0, end0;
        uint64_t start1, end1;
        uint64_t start2, end2;
        uint64_t start3, end3;
}

Then have a max-nodes value per machine, and a pointer to a
node_memregion array. If you only have one node, which would be the
common case, then you populate just that specifying the holes you have
etc. A simple function can then calculate the maximum allowable memory
in a generic way.

Simple to define for all the simple boards.

Jes