On 06/17/2012 03:43 PM, Blue Swirl wrote: > On Sun, Jun 17, 2012 at 11:51 AM, Avi Kivity <a...@redhat.com> wrote: >> On 06/17/2012 02:47 PM, Jan Kiszka wrote: >>>>> >>>>> I think this should rather go into generic code. >>>> >>>> To be honest, I put this in kvm-specific code because vl.c doesn't have >>>> TARGET_PAGE_ALIGN. Maybe we should have machine->page_size or >>>> machine->ram_alignment. >>>> >>>>> What sense does it make >>>>> to have partial pages with TCG? >>>> >>>> Why impose an artificial restriction? >>> >>> Beca... >>> >>>> >>>> (answer: to reduce differences among various accelerators) >>>> >>> >>> Oh, you found the answer. :) >> >> Reducing round-trips across the Internet. >> >>> >>> At least, it should be enforce for the x86 target, independent of the >>> accelerator. >> >> Yeah. So there's machine->page_size or machine->ram_alignment. Not >> sure which is best. > > The boards should make sure that the amount of RAM is feasible with > the board memory slots. It's not possible to put 256kb SIMMs to a slot > that expects 1GB DIMMs. We can allow some flexibility there though, > I'm not sure if the current chipsets would support very much memory if > we followed the docs to the letter.
Right. And generally memory modules are sized a power of two, creating the silly "mega == 1048576" movement. > > Maybe strtosz() should just enforce 1MB granularity. strtosz() is much too general. We could do it in vl.c without trouble. However, it takes away our ability to emulate a "640k should be enough for everyone" machine. > > What about ballooning (memory hotplug?), can that reduce the memory by > smaller amount than page size? Ballooning removes individual pages, that has no effect on the slot size. -- error compiling committee.c: too many arguments to function
