From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IbxxC-0005WK-Ke for qemu-devel@nongnu.org; Sun, 30 Sep 2007 08:31:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IbxxB-0005Vw-Gs for qemu-devel@nongnu.org; Sun, 30 Sep 2007 08:31:22 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbxxB-0005Vq-CR for qemu-devel@nongnu.org; Sun, 30 Sep 2007 08:31:21 -0400 Received: from honiara.magic.fr ([195.154.193.36]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IbxxA-0003hE-Py for qemu-devel@nongnu.org; Sun, 30 Sep 2007 08:31:21 -0400 Subject: Re: [Qemu-devel] Updated >2G memory patch From: "J. Mayer" In-Reply-To: References: <1191072882.29900.39.camel@rapid> <200709292343.19562.paul@codesourcery.com> <1191107818.29900.53.camel@rapid> Content-Type: text/plain Date: Sun, 30 Sep 2007 14:31:17 +0200 Message-Id: <1191155477.29900.123.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: Blue Swirl Cc: qemu-devel@nongnu.org On Sun, 2007-09-30 at 10:15 +0300, Blue Swirl wrote: > On 9/30/07, J. Mayer wrote: > > 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. > > I think Qemu is a geek application. The majority of people with their > i386 Windows PCs don't know or care about, for example Sparc32 > targets, or even about Qemu. The people who know about Qemu are > probably geeks, they already have some kind of need to emulate > hardware. I'd think majority of them still want to emulate an i386 > target on their i386/x86_64 host. Other targets and hosts are a > minority, making the people interested in those even geekier. > > But whether this patch or something else is a geek feature or not is > irrelevant. What matters is whether it breaks something or not, or if > some part of the design is objectionable. I fully agree with you that > some parts could be designed differently. About the design, my opinion is: - to support wider physical address spaces: * full 32 bits targets (ie 32 bits virtual & physical address spaces) should stay 32 bits. * for 32 bits targets with a few more bits for their physical address space (like the ppcemb target, which has 36 bits of physical address space and I guess x86 with PAE extension), it seems acceptable to only adjust the L1_BITS constants. * for 64 bits targets, a multiple level table has to be used to avoid the need of huge l1_xxx tables. This includes the alpha target (42 bits of physical address space), for which I recognize the quick hack I did commit is not really acceptable. - to support more than 2 GB of RAM: I still think you should have to use a consistent type here, not just unsigned long. Do you really need another new type ? It seems to me that one of physical_addr_t or ram_addr_t could be used ? -- J. Mayer Never organized