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