From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DvkQT-0006w6-2W for qemu-devel@nongnu.org; Thu, 21 Jul 2005 19:26:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DvkQJ-0006tW-DS for qemu-devel@nongnu.org; Thu, 21 Jul 2005 19:25:52 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DvkQG-0006ho-TR for qemu-devel@nongnu.org; Thu, 21 Jul 2005 19:25:49 -0400 Received: from [195.250.128.75] (helo=smtp2.vol.cz) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DvkA0-0004ho-6F for qemu-devel@nongnu.org; Thu, 21 Jul 2005 19:09:00 -0400 Received: from [10.0.0.2] (prg-v-6-220.static.adsl.vol.cz [62.177.70.220]) by smtp2.vol.cz (Postfix) with ESMTP id C1F2F60E39 for ; Fri, 22 Jul 2005 00:58:56 +0200 (CEST) Message-ID: <42E028B3.3080400@reactos.com> Date: Fri, 22 Jul 2005 00:58:59 +0200 From: Filip Navara MIME-Version: 1.0 Subject: Re: [Qemu-devel] PowerPC64 and more References: <1121944537.9483.74.camel@rapid> <42E01D41.8020108@reactos.com> <1121985441.9483.97.camel@rapid> In-Reply-To: <1121985441.9483.97.camel@rapid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 J. Mayer wrote: >On Fri, 2005-07-22 at 00:10 +0200, Filip Navara wrote: > > >>J. Mayer wrote: >> >> >> >>>Here's a long awaited patch (hum, Fabrice ? ;-) ). >>>It is really invasive in the target-ppc subdirectory. >>> >>> >>> >>> >>[snip] >> >>wow, you repeated my and Fabrice's mistake once more ... think about the >>code below more :) >>note: when you'll be done thinking or run out of ideas see my x86-64 >>patches that i sent to ML this morning. >> >> > >Without this patch, it crashes at the first instruction trying to access >the BIOS. >And your patch does not solve the problem: >on a real PowerPC 64 machine, we can use the whole 64 bits virtual >space. >We agreed with Fabrice that there should be at least one more >indirection in page mapping, because it would cost too much memory to >try to map the whole needed memory space in one table, even if we can >"forget" some of the middle bits in most cases. > > Ok, so far so good and I agree with that (I even had the third level of indirection implemented)... >Then, you're right, this patch is ugly but allows not to crash until we >have a correct solution with indirect tables to get a very large virtual >space. > > > ... but read it once more. You're cutting up the "index", not "index >> L2_BITS". - Filip >>Index: exec.c >>=================================================================== >>RCS file: /cvsroot/qemu/qemu/exec.c,v >>retrieving revision 1.60 >>diff -u -d -w -B -b -d -p -r1.60 exec.c >>--- exec.c 24 Apr 2005 18:02:38 -0000 1.60 >>+++ exec.c 20 Jul 2005 23:00:26 -0000 >>@@ -257,6 +257,10 @@ static inline VirtPageDesc *virt_page_fi >> { >> VirtPageDesc *p; >> >>+ /* XXX: should not truncate for 64 bit addresses */ >>+#if TARGET_LONG_BITS > 32 >>+ index &= (L1_SIZE - 1); >>+#endif >> p = l1_virt_map[index >> L2_BITS]; >> if (!p) >> return 0; >> >> > > >