From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgF0P-00064m-6Y for qemu-devel@nongnu.org; Sun, 17 Jun 2012 08:55:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SgF0N-00064D-Bl for qemu-devel@nongnu.org; Sun, 17 Jun 2012 08:55:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgF0N-000647-3s for qemu-devel@nongnu.org; Sun, 17 Jun 2012 08:54:59 -0400 Message-ID: <4FDDD39D.9090800@redhat.com> Date: Sun, 17 Jun 2012 15:54:53 +0300 From: Avi Kivity MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] kvm: align ram_size to page boundary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Michael Tokarev , Marcelo Tosatti , Jan Kiszka , qemu-devel@nongnu.org, 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