From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ibt19-0004BR-KI for qemu-devel@nongnu.org; Sun, 30 Sep 2007 03:15:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ibt18-0004BF-53 for qemu-devel@nongnu.org; Sun, 30 Sep 2007 03:15:06 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ibt17-0004BC-Uz for qemu-devel@nongnu.org; Sun, 30 Sep 2007 03:15:05 -0400 Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ibt17-0002XG-LA for qemu-devel@nongnu.org; Sun, 30 Sep 2007 03:15:05 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ibt16-0003Tw-UQ for qemu-devel@nongnu.org; Sun, 30 Sep 2007 03:15:05 -0400 Received: by nf-out-0910.google.com with SMTP id 30so2553123nfu for ; Sun, 30 Sep 2007 00:15:02 -0700 (PDT) Message-ID: Date: Sun, 30 Sep 2007 10:15:02 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] Updated >2G memory patch In-Reply-To: <1191107818.29900.53.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1191072882.29900.39.camel@rapid> <200709292343.19562.paul@codesourcery.com> <1191107818.29900.53.camel@rapid> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "J. Mayer" Cc: qemu-devel@nongnu.org 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.