From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JKyJP-0004pg-PO for qemu-devel@nongnu.org; Fri, 01 Feb 2008 11:00:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JKyJO-0004pA-C9 for qemu-devel@nongnu.org; Fri, 01 Feb 2008 11:00:19 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKyJO-0004p7-79 for qemu-devel@nongnu.org; Fri, 01 Feb 2008 11:00:18 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JKyJN-0000df-K0 for qemu-devel@nongnu.org; Fri, 01 Feb 2008 11:00:18 -0500 From: Paul Brook Date: Fri, 1 Feb 2008 16:00:09 +0000 References: <1201818980-27534-1-git-send-email-aliguori@us.ibm.com> <47A2F3C7.6060409@bellard.org> <47A32E40.3000204@us.ibm.com> In-Reply-To: <47A32E40.3000204@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802011600.10877.paul@codesourcery.com> 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: Anthony Liguori Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org > > 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 :-) I'd say ram_addr_t is an appropriate type. Currently this is defined in cpu-defs.h. It should probably be moved elsewhere because in the current implementation it's really a host type. If we ever implement >2G ram on a 32-bit host this may need some rethinking. We can deal with that if/when it happens though. Requiring a 64-bit host for large quantities of ram seems an acceptable limitation (N.B. I'm only talking about ram size, not target physical address size). Paul