From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 1/6] Use correct types to enable > 2G support Date: Thu, 31 Jan 2008 18:25:56 -0600 Message-ID: <47A26714.4000204@us.ibm.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org, Avi Kivity , Fabrice Bellard To: Paul Brook Return-path: In-Reply-To: <200801312354.24382.paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.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 > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/