From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dvwog-0006V7-OQ for qemu-devel@nongnu.org; Fri, 22 Jul 2005 08:39:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dvwoe-0006UN-FB for qemu-devel@nongnu.org; Fri, 22 Jul 2005 08:39:49 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dvwjk-0004vd-1V for qemu-devel@nongnu.org; Fri, 22 Jul 2005 08:34:44 -0400 Received: from [62.210.190.9] (helo=brazzaville.magic.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DvwLI-0004oy-WF for qemu-devel@nongnu.org; Fri, 22 Jul 2005 08:09:29 -0400 Received: from [192.168.0.2] (ppp-36.net-723.magic.fr [80.118.184.36]) by brazzaville.magic.fr (8.11.6/8.11.6) with ESMTP id j6MBxFN30833 for ; Fri, 22 Jul 2005 13:59:15 +0200 Subject: Re: [Qemu-devel] PowerPC64 and more From: "J. Mayer" In-Reply-To: <42E028B3.3080400@reactos.com> References: <1121944537.9483.74.camel@rapid> <42E01D41.8020108@reactos.com> <1121985441.9483.97.camel@rapid> <42E028B3.3080400@reactos.com> Content-Type: text/plain Date: Fri, 22 Jul 2005 13:56:52 +0200 Message-Id: <1122033412.9483.133.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:58 +0200, Filip Navara wrote: > J. Mayer wrote: > > >On Fri, 2005-07-22 at 00:10 +0200, Filip Navara wrote: > > > > > >>J. Mayer wrote: [...] > >>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". In fact, I did not want to be too invasive outside of target-ppc subdirectory. Then I found that Fabrice did a patch in virt_page_find_alloc for x86_64 support (a few lines above in the same file). I have to admit I just duplicated this hack and it solved my crashes. As the address that generated the crash was 0xFFFFFFFFFFFFFFFC (-4), I just admitted that it would prevent the crash for any address... I even did not check if the mask was the right one, in fact... [...] -- J. Mayer Never organized