qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] Shifts, ppc[64], xtensa
Date: Wed, 19 Sep 2012 18:11:05 +0100

On 19 September 2012 18:00, Richard Henderson <address@hidden> wrote:
> On 09/19/2012 05:57 AM, Peter Maydell wrote:
>>> > -            s->code_ptr += 16;
>>> > +            tcg_out32 (s, NOP);
>>> > +            tcg_out32 (s, NOP);
>>> > +            tcg_out32 (s, NOP);
>>> > +            tcg_out32 (s, NOP);
>> Not too familiar with the PPC backend, but doesn't this mean that
>> in the retranslation case we will overwrite a correct jump destination
>> with these NOP words and then rewrite it again with the correct
>> destination? That can cause problems with cache incoherency;
>> compare the fix applied in commit c69806ab8276 for ARM.
>
> Well, i386 certainly doesn't care about re-translation here:

i386 is weird (as usual) in that it maintains i/d side cache
coherency entirely automatically. I don't know about PPC,
but explicit cache maintenance is more common for RISC...

> And as far as the referenced change, that has to do with "real"
> branches, i.e. INDEX_op_brcond et at.  Which *do* need to be
> protected against retranslation.  But INDEX_op_goto_tb is a
> different case.

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.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]