From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dvju0-0007Xz-Hs for qemu-devel@nongnu.org; Thu, 21 Jul 2005 18:52:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dvjtr-0007Sp-KD for qemu-devel@nongnu.org; Thu, 21 Jul 2005 18:52:26 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dvjtp-0007Oq-Iq for qemu-devel@nongnu.org; Thu, 21 Jul 2005 18:52:17 -0400 Received: from [62.210.158.45] (helo=quito.magic.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DvjrW-0003a7-JK for qemu-devel@nongnu.org; Thu, 21 Jul 2005 18:49:54 -0400 Received: from [192.168.0.2] (ppp-36.net-723.magic.fr [80.118.184.36]) by quito.magic.fr (8.11.6/8.11.2) with ESMTP id j6LMdnG11972 for ; Fri, 22 Jul 2005 00:39:49 +0200 (CEST) Subject: Re: [Qemu-devel] PowerPC64 and more From: "J. Mayer" In-Reply-To: <42E01D41.8020108@reactos.com> References: <1121944537.9483.74.camel@rapid> <42E01D41.8020108@reactos.com> Content-Type: text/plain Date: Fri, 22 Jul 2005 00:37:21 +0200 Message-Id: <1121985441.9483.97.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 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. 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. > 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; -- J. Mayer Never organized