Re: [Qemu-devel] MTTCG next version?

[Emilio G. Cota]

On Wed, Aug 26, 2015 at 14:18:24 +0200, Frederic Konrad wrote:
> Do that make sense?

A few decisions here don't make that much sense to me, but maybe
I'm missing context:

> I'm trying to do the next version of the MTTCG work:
> 
> I would like to rebase on Alvise atomic instruction branch:
>   - Alvise can you rebase it on the 2.4.0 version without MTTCG
> support and then
>     point me to the MTTCG specific changes so I can include them in
> my tree?

This breaks usermode--what's the way forward for that?

> About tb_flush we think to do that without exiting:
>   - Use two buffers for tbs.
>   - Use a per tb invalidated flag.
>   - when tb_flush just invalidate all tb from the buffer and swap to
> the second buffer:
>     VCPU which are executing code will discard their tb_jmp_cache
> when they exit
>     (eg: run_on_cpu).

What's wrong with exiting? tb_flush is called very rarely so the perf
impact is not a factor--reliability and simplicity are more important
goals. Exiting/halting all CPUs seems like the easiest way to
achieve said goals.

> We need also to fix emulated data barrier so tlb_flush are finished
> before the
> instruction is executed. (That might be only data barrier breaks the TB).

I suggest to look at solutions that make the requesting CPU thread
to wait until all TLB invalidations have completed--in other words,
the effect of said actions from the guest's viewpoint should be 'immediate'.
This way we don't have to worry about interactions between the TLB
invalidation instruction and subsequent instructions.

This principle applies to other actions on global state, such as tb_flush.

FWIW the patchset I sent on Sunday is one way of doing this.

Cheers,

                Emilio