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