From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcPSm-0007Z8-8C for qemu-devel@nongnu.org; Thu, 30 Jun 2011 18:11:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcPSk-0007MK-R1 for qemu-devel@nongnu.org; Thu, 30 Jun 2011 18:11:55 -0400 Received: from ch1ehsobe003.messaging.microsoft.com ([216.32.181.183]:10015 helo=CH1EHSOBE015.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcPSk-0007MG-Fq for qemu-devel@nongnu.org; Thu, 30 Jun 2011 18:11:54 -0400 Date: Thu, 30 Jun 2011 17:11:47 -0500 From: Scott Wood Message-ID: <20110630171147.76eef3fc@schlenkerla.am.freescale.net> In-Reply-To: <10F3D94F-5B79-4041-BFE7-58681B7E89CB@suse.de> 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> <20110630111745.7c544a06@schlenkerla.am.freescale.net> <86AF921C-3FD1-409A-ACFD-EEEA23BBE130@suse.de> <20110630164630.2bd57166@schlenkerla.am.freescale.net> <10F3D94F-5B79-4041-BFE7-58681B7E89CB@suse.de> 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: Alexander Graf Cc: qemu-devel@nongnu.org, Fabien Chouteau On Thu, 30 Jun 2011 23:56:17 +0200 Alexander Graf wrote: > > On 30.06.2011, at 23:46, Scott Wood wrote: > > > On Thu, 30 Jun 2011 23:34:37 +0200 > > Alexander Graf wrote: > > > >> We could just keep an internal counter that memorizes how much memory is locked and sets the bit after exceeding the fake cache size. > > > > And keep track of unlocks, decrementing the counter only if the address was > > already locked... seems better to keep it simple and just be honest about > > the failure until a real need for trickery arises. > > > >> The only problem I could see remaining is that CAR could potentially fail, as it can access addresses in cache directly that don't have to have underlying RAM mapped. However, I'd hope that only firmware does this and we usually don't execute real firmware in qemu :) > > > > This is a case where it would be nice for the guest to see the failure > > indication, if we're lucky enough that it bothers to check. > > > > But yeah, it's unlikely to happen outside of firmware. > > > >> Also, lock set instructions seem to raise DSIs, so we need to generate some loads that don't go anywhere. > > > > Yes. > > > > Note that dcbtstls is treated as a store, which is a little trickier. > > Not that much. It should be enough to simply do: > > st(addr, ld(addr)); > > no? Almost, but what if we have write permission but not read? I assume races among threads are taken care of by some mechanism whereby qemu only takes an interrupt on target instruction boundaries (does/will qemu simulate guest SMP?), but what about a race with DMA from the I/O thread? -Scott