From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEOQz-0005kx-TQ for qemu-devel@nongnu.org; Wed, 19 Sep 2012 13:51:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEOQy-00045K-JQ for qemu-devel@nongnu.org; Wed, 19 Sep 2012 13:51:37 -0400 Received: from hall.aurel32.net ([88.191.126.93]:44698) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEOQy-0003yk-BB for qemu-devel@nongnu.org; Wed, 19 Sep 2012 13:51:36 -0400 Date: Wed, 19 Sep 2012 19:51:16 +0200 From: Aurelien Jarno Message-ID: <20120919175116.GC29951@hall.aurel32.net> References: <5059FA36.1080301@twiddle.net> <505A011C.1020106@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <505A011C.1020106@twiddle.net> Sender: Aurelien Jarno Subject: Re: [Qemu-devel] Shifts, ppc[64], xtensa List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Peter Maydell , qemu-devel@nongnu.org, Max Filippov On Wed, Sep 19, 2012 at 10:30:04AM -0700, Richard Henderson wrote: > On 09/19/2012 10:11 AM, Peter Maydell wrote: > > Can you elaborate? If we're emitting a native branch insn > > and we're potentially changing the value in memory several > > times during retranslate I would have thought it still applied. > > For brcond, we always apply the relocation before we ever try to execute the TB. > > For goto_tb, we expect the contents of the patch to contain valid insns from the > start. We never apply a "null" relocation there. Perhaps this should be considerd > a bug in cpu_gen_code, but that's where we are. > There is no cache problem in that case, because the cache are synchronized just after the value is modified (see exec-all.h). That said it is not a valid reason to not keep the value during re-translation, as it means the TB will exit instead of linking to the next one. The consequences are only the performance. The real problem in the PPC case is that changing the jump address is not atomic. In some rare cases (but given the number of executed TB in system mode, it should be considered as probable), this might cause a jump to the wrong address. This is especially true when doing TB unlinking. That's one of the reason we are not doing direct jump on MIPS for example (that should be something possible, but with a lot of constraints on the size and location of the code gen buffer). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net