From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJ5dW-0003RT-KM for qemu-devel@nongnu.org; Sat, 03 Jan 2009 07:29:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJ5dW-0003RH-0v for qemu-devel@nongnu.org; Sat, 03 Jan 2009 07:29:50 -0500 Received: from [199.232.76.173] (port=39740 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJ5dV-0003RE-T6 for qemu-devel@nongnu.org; Sat, 03 Jan 2009 07:29:49 -0500 Received: from hall.aurel32.net ([88.191.82.174]:42245) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LJ5dV-0006YF-HE for qemu-devel@nongnu.org; Sat, 03 Jan 2009 07:29:49 -0500 Date: Sat, 3 Jan 2009 13:29:43 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] [RFC] MIPS CP0 random register strategy Message-ID: <20090103122943.GA18974@volta.aurel32.net> References: <495D1BBB.6090204@reactos.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <495D1BBB.6090204@reactos.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-15?Q?Herv=E9?= Poussineau Cc: qemu-devel@nongnu.org On Thu, Jan 01, 2009 at 08:38:35PM +0100, Hervé Poussineau wrote: > Hello, Hi! > MIPS TLBWR instruction asks the CPU to randomly overwrite a TLB entry by > the one we want to write. The TLB index needs to be between number of > wired TLB entries and TLB count - 1. > However, algorithm to choose which one to overwrite is implementation > dependant. > > After checking MIPS CPU documentations, 4 algorithms are emerging: > - Random register is decremented once at each clock tick > - Random register is decremented once after 'number of wired TLB > entries' clock ticks > - Random register is decremented only after TLBWR instruction > - Random register uses a Not Last Used algorithm, ie whatever value > which is not the previous one > > At the moment, Qemu implementation seems to be more the 4th one, but can > return the same value more than once. > Due to this, NetBSD 1.6.2 on MIPS Magnum emulation crashes. > > Attached patch tries to fix the problem by adding 4 methods to update > Random value. > Each CPU needs to define which Random algorithm it is using. After looking to the patch, I am not sure we really want to implement the 4 different methods. On the 4 different methods, only the one which decrement the random register actually corresponds to what the real CPU does. The instruction rate in QEMU is not related to the clock ticks, which makes the two algorithms based on clock ticks non-accurate, and the LRU algorithm which is implemented is actually a random algorithm. If we look at the 4 algorithm, what seems to be important is: - having something more or less random - not returning the same value twice What about only modifying the current algorithm to fix the second point? > Patch also optimizes CP0_Random access, by not requiring call to a > helper function This seems to be wrong, two reads from CP0_Random will return the same value, which is wrong at least for some algorithms. > Finally, it initializes CP0_Random even in user mode emulation, which > was not the case before. Also please note, that you patch breaks the read from CP0_Count. Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net