From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcJwA-0006Sm-0k for qemu-devel@nongnu.org; Thu, 30 Jun 2011 12:17:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcJw8-0003uP-Hi for qemu-devel@nongnu.org; Thu, 30 Jun 2011 12:17:53 -0400 Received: from am1ehsobe002.messaging.microsoft.com ([213.199.154.205]:30794 helo=AM1EHSOBE002.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcJw8-0003ts-3C for qemu-devel@nongnu.org; Thu, 30 Jun 2011 12:17:52 -0400 Date: Thu, 30 Jun 2011 11:17:45 -0500 From: Scott Wood Message-ID: <20110630111745.7c544a06@schlenkerla.am.freescale.net> In-Reply-To: <4E0C32FB.40302@adacore.com> References: <1309180555-3942-1-git-send-email-chouteau@adacore.com> <20110627112807.22346e82@schlenkerla.am.freescale.net> <4E098E23.3040605@adacore.com> <20110628112008.31cf6237@schlenkerla.am.freescale.net> <4E0C32FB.40302@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Add e500 instructions dcblc, dcbtls and dcbtstl as no-op List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fabien Chouteau Cc: qemu-devel@nongnu.org On Thu, 30 Jun 2011 10:25:31 +0200 Fabien Chouteau wrote: > On 28/06/2011 18:20, Scott Wood wrote: > > On Tue, 28 Jun 2011 10:17:39 +0200 > > Fabien Chouteau wrote: > > > >> Why do you want to set this bit? Can't we consider that the instruction is > >> always effective? > > > > But it's not. Why claim it is, in the absence of some specific workload > > that needs to be fooled (which could take many different forms, not all of > > which are appropriate defaults)? > > Reading the e500 manual again, it's not clear to me what can make the > L1CSR0[CUL] to be set. If you have a better understanding, can you please > explain? > L1CSR0[CUL] is set whenever a lock set instruction fails to lock (typically because all ways of the set are already locked). Since we don't support cache locking in qemu, these instructions always fail, and thus CUL should always be set. Regarding what behavior would maximize compatibility, while it's conceivable that some program could break if it sees the bit set when it was expecting to be able to succeed, also consider a program that might keep locking until it sees the bit set to determine how much cache it can lock. -Scott