Re: [Qemu-devel] [RFC 6/7] [XXX] tcg: make TCGContext thread-local for softmmu

[Richard Henderson]

On 06/29/2017 01:28 PM, Emilio G. Cota wrote:
> This will allow us to generate TCG code in parallel.
>
> User-mode is kept out of this: contention due to concurrent translation
> is more commonly found in full-system mode (e.g. booting a many-core guest).
>
> XXX: For now, only convert arm/a64, since these are the only guests that
> have proper MTTCG support.

Not true.  TCG_GUEST_DEFAULT_MO suggests we have 4.

> XXX: This is calling prologue_init once per vCPU, i.e. each TCGContext
>       gets a different prologue/epilogue (all of them with the same
>       contents though). Far from ideal, but for an experiment it
>       "should" work, right?

Um... sure.  But surely there's a better way.  Perhaps copying the main 
thread's tcg_ctx?  That'd be after prologue, and target globals are created. 
That would avoid the need to make all the target cpu_* globals be thread-local, 
for instance.

Of course, now that I think of it, this implies that my tcg patches to use 
pointers instead of indicies is not the Way Forward...

>   /* Share the TCG temporaries common between 32 and 64 bit modes.  */
> -extern TCGv_env cpu_env;
> -extern TCGv_i32 cpu_NF, cpu_ZF, cpu_CF, cpu_VF;
> -extern TCGv_i64 cpu_exclusive_addr;
> -extern TCGv_i64 cpu_exclusive_val;
> +extern TCG_THREAD TCGv_env cpu_env;
> +extern TCG_THREAD TCGv_i32 cpu_NF, cpu_ZF, cpu_CF, cpu_VF;
> +extern TCG_THREAD TCGv_i64 cpu_exclusive_addr;
> +extern TCG_THREAD TCGv_i64 cpu_exclusive_val;

It would be Really Good if we could avoid this in the end.
I see that it's the quickest way to test for now though.

> @@ -887,7 +893,7 @@ typedef struct TCGOpDef {
>   #endif
>   } TCGOpDef;
>   
> -extern TCGOpDef tcg_op_defs[];
> +extern TCG_THREAD TCGOpDef tcg_op_defs[];

Why?  It's constant after startup.


r~