On Sun, Jun 17, 2012 at 12:54 PM, Avi Kivity <a...@redhat.com> wrote: > 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.
Then how about current max of target page sizes: 8k? No machine should want less than that. > >> >> 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 > >
