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

[Blue Swirl]

On Mon, Apr 4, 2011 at 5:53 PM, Jes Sorensen <address@hidden> wrote:
> On 04/04/11 16:42, Peter Maydell wrote:
>> On 4 April 2011 15:29, Jes Sorensen <address@hidden> wrote:
>>>> Yes, I agree, so we shouldn't try to specify some complicated
>>>> set of static data that still won't be good enough.
>>>>
>>>> I'm trying to make it easy for boards to avoid crashing horribly
>>>> when the user passes a bad value; that's all.
>>>
>>> If you don't validate properly, is there really a point in introducing
>>> that value anyway? From what you write, it sounds like it can still fail
>>> for some limits of the memory valid if the config is wrong?
>>
>> For the boards I care about (the ARM ones), the only validation
>> requirement is that we don't allow the user to specify so much
>> ram that we overlap physical RAM with I/O space. So ram_size is
>> good enough. For the sun4m boards we can assume that the only
>> validation they need is a ram_size check, because that's all they
>> do at the moment and nobody's complaining that I know of.
>
> 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.

We could have "-device RAM,base=xxx,size=yyy,id=DIMM1 -numa
nodeid=zzz,memory=DIMM1" for fine tuned control.

But asking users to list and bind the DIMMs needed just to have some
amount of RAM is a bit too much. So we also need a simple case (-m)
and a simple check for the max memory.

It's still possible for the board to do additional checks and even use
heuristics to invent the DIMMs.

>>> It still seems to me it would be better to have the boards present a
>>> table of valid memory ranges so we can do a proper validation of the valud?
>>
>> If you have a concrete example of multiple boards which we currently model
>> and which require this level of flexibility to avoid odd misbehaviour trying
>> to run a guest, then please point them out and I'll look at expanding the
>> patch to cover their requirements.
>>
>> If this is just a theoretical issue, then I think we should only add the
>> extra generic framework code if and when we turn out to need it.
>
> 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.
>
> Having an a table of valid ram locations for a board, will also give you
> a framework to validate against if you want to be able to specify chunks
> of memory at different areas of a board. This could be useful for
> testing behavior that is like it would be if you have a system where
> installing different DIMMs would split the RAM up differently.

Maybe we could remove some of memory logic in pc.c with this approach.

By the way, fw_cfg only uses one number for the memory size. This
should be changed. Alternatively the BIOSes could do a more realistic
RAM probe, but that would be wasteful.