Re: [RFC PATCH v1 2/2] Enable custom instruction suport for Andes A25 and AX25 CPU model

[Alex Bennée]

Ruinland ChuanTzu Tsai <ruinland@andestech.com> writes:

> On Thu, Oct 21, 2021 at 12:17:47PM -0700, Richard Henderson wrote:
>> On 10/21/21 8:11 AM, Ruinland Chuan-Tzu Tsai wrote:
>> > In this patch, we demonstrate how Andes Performance Extension(c) insn :
>> > bfos and bfoz could be used with Andes CoDense : exec.it.
>> > 
<snip>
>> > +static int andes_v5_gen_codense_exec_it(CPURISCVState *env, DisasContext 
>> > *ctx, arg_execit *a)
>> > +{
>> > +    uint32_t insn;
>> > +    uint32_t imm_ex10 = a->imm_codense;
>> > +    target_ulong uitb_val = 0;
>> > +    riscv_csrrw(env, 0x800, &uitb_val, 0, 0);
>> 
>> This won't work -- you can't access env during translation.  So all this
>> faff around passing env through HartState is for naught.
>
> Sorry, please elaborate me a little bit more.

When dealing with translation you need to separate the translation phase
from the execution phase. CPUEnv is the current run time state of the
vCPU so the value that might be stored in it when you do translation
could very well be different when the translation runs (or runs again).

The correct way to deal with this is by the use of translation flags. If
for example the translation is only valid for a particular execution
state you represent that in a translation flag which you compute in
cpu_get_tb_cpu_state. This ensures that the translated block will only
get looked up when you are in that translation state - if it's not you
will generate a new block for the current state. See the section:

 https://qemu.readthedocs.io/en/latest/devel/tcg.html#cpu-state-optimisations

of the developer guide.

-- 
Alex Bennée