From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JKjjE-00035r-Py for qemu-devel@nongnu.org; Thu, 31 Jan 2008 19:26:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JKjjC-00035W-B8 for qemu-devel@nongnu.org; Thu, 31 Jan 2008 19:25:59 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKjjC-00035T-5G for qemu-devel@nongnu.org; Thu, 31 Jan 2008 19:25:58 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JKjjC-0003qj-0J for qemu-devel@nongnu.org; Thu, 31 Jan 2008 19:25:58 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m110Puw2023727 for ; Thu, 31 Jan 2008 19:25:56 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m110Pu5E177292 for ; Thu, 31 Jan 2008 17:25:56 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m110PtHZ005377 for ; Thu, 31 Jan 2008 17:25:55 -0700 Message-ID: <47A26714.4000204@us.ibm.com> Date: Thu, 31 Jan 2008 18:25:56 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1201818980-27534-1-git-send-email-aliguori@us.ibm.com> <1201818980-27534-2-git-send-email-aliguori@us.ibm.com> <200801312354.24382.paul@codesourcery.com> In-Reply-To: <200801312354.24382.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: kvm-devel@lists.sourceforge.net, Izik Eidus , qemu-devel@nongnu.org Paul Brook wrote: > On Thursday 31 January 2008, Anthony Liguori wrote: > >> KVM supports more than 2GB of memory for x86_64 hosts. The following patch >> fixes a number of type related issues where int's were being used when they >> shouldn't have been. It also introduces CMOS support so the BIOS can build >> the appropriate e820 tables. >> > > You've still got a fairly random mix of unsigned long, ram_addr_t and > uint64_t. > I wasn't the one that did this work, but we've tested KVM with very large amounts of memory (~15GB I believe). I suspect the changes were driven by trial and error. Perhaps Izik can shed more light on how things were changed? >> -typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size, >> +typedef void QEMUMachineInitFunc(ram_addr_t ram_size, int vga_ram_size, >> > > This breaks every target except x86. > > Indeed. I missed this because it's only a warning since it's just a pointer cast. I'll fix the patch for all the remaining targets. Thanks! >> + if (above_4g_mem_size) { >> + rtc_set_memory(s, 0x5b, (unsigned int)above_4g_mem_size >> 16); >> + rtc_set_memory(s, 0x5c, (unsigned int)above_4g_mem_size >> 24); >> + rtc_set_memory(s, 0x5d, above_4g_mem_size >> 32); >> > > This will cause warnings on 32-bit hosts. > Yeah, it needs a (uint64_t), I'll update. >> +#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL) >> > > This seems fairly arbitrary. Why? Any limit is certainly target specific. > On a 32-bit host, a 2GB limit is pretty reasonable since you're limited in virtual address space. On a 64-bit host, there isn't this fundamental limit. If a target may have it's own limit but there is definitely a host imposed limit. 2047GBs is a somewhat arbitrary limit though for 64-bit hosts. If you have a more logical suggestion, I'll happily change it. Regards, Anthony Liguori > Paul >