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

[Jes Sorensen <Jes.Sorensen@redhat.com>]

On 04/04/11 18:54, Blue Swirl wrote:
> On Mon, Apr 4, 2011 at 5:53 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> 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.

I totally agree, but the suggestion I proposed earlier doesn't in any
way prevent this. If we use a table of valid memory locations for a
given board, then it is really easy for each board to provide a
validation function which accepts the amount or rejects 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.

I believe it would simplify things a great deal, and have the benefit
that we can emulate things much more realistically. The only issue is
that it takes a little more work up front, but it really isn't a big deal.

Cheers,
Jes