From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JL014-0005GS-ME for qemu-devel@nongnu.org; Fri, 01 Feb 2008 12:49:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JL012-0005Cc-LJ for qemu-devel@nongnu.org; Fri, 01 Feb 2008 12:49:29 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JL012-0005C1-2v for qemu-devel@nongnu.org; Fri, 01 Feb 2008 12:49:28 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JL011-0006SJ-PC for qemu-devel@nongnu.org; Fri, 01 Feb 2008 12:49:27 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m11Hp0Su012153 for ; Fri, 1 Feb 2008 12:51:00 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m11Hn7Yg273092 for ; Fri, 1 Feb 2008 12:49:07 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m11Hn7nj027652 for ; Fri, 1 Feb 2008 12:49:07 -0500 Message-ID: <47A35B96.9090303@us.ibm.com> Date: Fri, 01 Feb 2008 11:49:10 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1201818980-27534-1-git-send-email-aliguori@us.ibm.com> <47A2F3C7.6060409@bellard.org> <47A32E40.3000204@us.ibm.com> <200802011600.10877.paul@codesourcery.com> In-Reply-To: <200802011600.10877.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [kvm-devel] [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, qemu-devel@nongnu.org Paul Brook wrote: >>> 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. > Okay, it turns out that patch needed a lot of refactoring. I agree that changing ram_addr_t to a host type is the right thing to do. > 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). > My current limitation is < 2GB if HOST_BITS==32 or defined(USE_KQEMU). USE_KQEMU restricts the size of the phys_map which limits the maximum physical address size. I guess technically USE_KQEMU could allow up to around 3GB of ram but I preferred to simplify the logic. 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/ > _______________________________________________ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel >