From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JKwzv-0006ip-Ha for qemu-devel@nongnu.org; Fri, 01 Feb 2008 09:36:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JKwzs-0006hA-N8 for qemu-devel@nongnu.org; Fri, 01 Feb 2008 09:36:06 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKwzs-0006h2-BM for qemu-devel@nongnu.org; Fri, 01 Feb 2008 09:36:04 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JKwzr-0002Bc-RZ for qemu-devel@nongnu.org; Fri, 01 Feb 2008 09:36:04 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m11Ea16a011238 for ; Fri, 1 Feb 2008 09:36:01 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m11EZp9h048078 for ; Fri, 1 Feb 2008 07:35:56 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m11EZoZV031126 for ; Fri, 1 Feb 2008 07:35:50 -0700 Message-ID: <47A32E40.3000204@us.ibm.com> Date: Fri, 01 Feb 2008 08:35:44 -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> <47A2F3C7.6060409@bellard.org> In-Reply-To: <47A2F3C7.6060409@bellard.org> 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: Fabrice Bellard Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org, Paul Brook Fabrice Bellard wrote: > Anthony Liguori wrote: >> + /* above 4giga memory allocation */ >> + if (above_4g_mem_size > 0) { >> + ram_addr = qemu_ram_alloc(above_4g_mem_size); >> + cpu_register_physical_memory(0x100000000, above_4g_mem_size, >> ram_addr); >> + } >> + > > Why do you need this ? All the RAM can be registered with a single > call. I fear you need to do that because of KVM RAM handling > limitations. On the x86, there is a rather large hole at the top of memory. Currently, we do separate allocations around this whole. You can't get away from doing multiple cpu_register_physical_memory calls here. We've discussed just allocating a single chunk with qemu_ram_alloc since so many places in QEMU assume that you can do phys_ram_base + PA. I think I'll change this too into a single qemu_ram_alloc. That will fix the bug with KVM when using -kernel and large memory anyway :-) >> Index: qemu/osdep.c >> =================================================================== >> --- qemu.orig/osdep.c 2008-01-30 13:47:00.000000000 -0600 >> +++ qemu/osdep.c 2008-01-30 13:47:31.000000000 -0600 >> @@ -113,7 +113,7 @@ >> int64_t free_space; >> int ram_mb; >> >> - extern int ram_size; >> + extern int64_t ram_size; >> free_space = (int64_t)stfs.f_bavail * stfs.f_bsize; >> if ((ram_size + 8192 * 1024) >= free_space) { >> ram_mb = (ram_size / (1024 * 1024)); >> @@ -202,7 +202,7 @@ >> #ifdef _BSD >> return valloc(size); >> #else >> - return memalign(4096, size); >> + return memalign(TARGET_PAGE_SIZE, size); >> #endif >> } > > No fully correct because it is intended to be the host page size. Indeed. I'm dropping this. It was added for the ia64 port and since that's not included in this patch set, I'll let them fix it properly when they submit support for ia64. >> +extern int64_t ram_size; > > I agree with the fact that ram_size should be 64 bit. Maybe each > machine could test the value and emit an error message if it is too > big. Maybe an uint64_t would be better though. uint64_t is probably more reasonable. I wouldn't begin to know what the appropriate amount of ram was for each machine though so I'll let the appropriate people handle that :-) Regards, Anthony Liguori > Fabrice.