From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IblYa-0006xL-PE for qemu-devel@nongnu.org; Sat, 29 Sep 2007 19:17:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IblYY-0006x9-8s for qemu-devel@nongnu.org; Sat, 29 Sep 2007 19:17:07 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IblYY-0006x6-3l for qemu-devel@nongnu.org; Sat, 29 Sep 2007 19:17:06 -0400 Received: from bangui.magic.fr ([195.154.194.245]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IblYX-0003Le-Ij for qemu-devel@nongnu.org; Sat, 29 Sep 2007 19:17:05 -0400 Subject: Re: [Qemu-devel] Updated >2G memory patch From: "J. Mayer" In-Reply-To: <200709292343.19562.paul@codesourcery.com> References: <1191072882.29900.39.camel@rapid> <200709292343.19562.paul@codesourcery.com> Content-Type: text/plain Date: Sun, 30 Sep 2007 01:16:57 +0200 Message-Id: <1191107818.29900.53.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl On Sat, 2007-09-29 at 23:43 +0100, Paul Brook wrote: > > > Also note that changing variables from int to long have strictly no > > > impact on 32 bits host machines, then won't help emulating more than 2 > > > GB of RAM. Another variable type (target_phys_addr_t ?) should be used > > > instead. > > > > This patch should be restricted to 64-bit hosts. I don't think it's > > useful to emulate a 64-bit target with huge amounts of virtual and > > physical address space on a 32-bit host. My feeling is that if it's restricted to 64 bits host, then it's a patch for geeks only, that brings no useful feature to the main end-users. In the real world, most people are still running in 32 bits mode. > IMHO Huge amounts of virtual address space can definitely be useful, even if > you don't have ram to back it. > > Huge amounts of physical address space is less immediately useful, though in > practice you have to emulate whatever real hardware provides. If you're > emulating a machine with a 40+ bit physical address space, there's a fair > chance your guest OS will decide to scatter a relatively small set of > resources over the whole address space. I don't agree too much with your opinion, because what I can see is that PowerPC 64 machines (at least IBM ones) tend to use the 62 bits physical address space provided by the architecture. If I remember well, there is at least one PPC64 architecture where the highest bits are used to split the physical address space between memory, memory-mapped IO, devices, ... I'm quite sure there are other 64 bits architecture that have the same requirement of a huge physical address space, then beeing able to handle it in Qemu seems to be very useful, much more than trying to emulate a huge amount of RAM, and is needed in a very near future. > I agree there's no point trying to emulate >2G ram on a 32-bit host, but > physical address space and ram are two very different things. > For example I have a cpu that has a "bitbanded" memory region. This expands > each bit of real ram to a whole 32-bit word, effectively turning a word > load/store into an atomic bit operation. Currently it's only used for > relatively small address ranges, but it's a good example of a situation where > the physical address space is much larger than ram. I don't see why it would be useless to emulate huge amount of RAM on 32 bits hosts. If you try to register more than a few gigabytes of memory, there are great chances that the host machine won't have the physical RAM to handle it at once, so a page swap mechanism will have to be implemented. Then, I see no difference in using it on a 32 bits hosts or a 64 bits ones. Regards. -- J. Mayer Never organized