Re: [Qemu-devel] Shifts, ppc[64], xtensa

[Aurelien Jarno <aurelien@aurel32.net>]

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