From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] kvm: align ram_size to page boundary Date: Sun, 17 Jun 2012 15:54:53 +0300 Message-ID: <4FDDD39D.9090800@redhat.com> References: <1339922831-23002-1-git-send-email-avi@redhat.com> <4FDDB981.8070309@web.de> <4FDDBFCD.3000608@redhat.com> <4FDDC3C8.5020205@web.de> <4FDDC4B6.5030202@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Tokarev , Marcelo Tosatti , Jan Kiszka , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Blue Swirl Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 06/17/2012 03:43 PM, Blue Swirl wrote: > On Sun, Jun 17, 2012 at 11:51 AM, Avi Kivity 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