Re: [Qemu-devel] [RFC 35/38] cputlb: use cpu_tcg_sched_work for tlb_flush_all

["Emilio G. Cota" <cota@braap.org>]

On Sun, Aug 23, 2015 at 18:29:33 -0700, Paolo Bonzini wrote:
> 
> 
> On 23/08/2015 17:24, Emilio G. Cota wrote:
> > Signed-off-by: Emilio G. Cota <cota@braap.org>
> > ---
> >  cputlb.c | 41 +++++++++++------------------------------
> >  1 file changed, 11 insertions(+), 30 deletions(-)
> 
> As suggested by me and Peter, synchronization on TLB flushes should be
> arch-specific.  CPUs can halt on a dmb if they have pending TLB flush
> requests on other CPUs,

I'm not sure I understand. With the patches I sent, a CPU that wants
to flush other TLBs does not continue execution until all of those TLBs
are flushed. So dsb/dmb whatever comes next would have nothing to
wait for. What am I missing?

> and the CPU can be woken up from the run_on_cpu
> callback with something like:
> 
>     if (--caller_cpu->pending_tlb_flush_request) {
>         caller_cpu->interrupt_request |= CPU_INTERRUPT_TLB_DONE;
>         qemu_cpu_kick(caller_cpu);
>     }
> 
> 
> ...
> 
> 
> static bool arm_cpu_has_work(CPUState *cs)
> {
>     ARMCPU *cpu = ARM_CPU(cs);
> 
>     return !cpu->pending_tlb_flush_request && !cpu->powered_off
>         && cs->interrupt_request &
>         (CPU_INTERRUPT_FIQ | CPU_INTERRUPT_HARD
>          | CPU_INTERRUPT_VFIQ | CPU_INTERRUPT_VIRQ
>          | CPU_INTERRUPT_EXITTB | CPU_INTERRUPT_TLB_DONE);
> }

Another option, which I tried but my TCG skills fail me, is to
protect each TLB with a seqlock.

The advantage of this is that TLB flushes would always complete
immediately, so there's no need to halt execution.

The disadvantage is the performance hit, but at least on TSO this
seems to me worth a shot.

Thanks,

		Emilio