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

[Paolo Bonzini]

----- Original Message -----
> From: "Emilio G. Cota" <address@hidden>
> To: "Paolo Bonzini" <address@hidden>
> Cc: address@hidden, address@hidden, "guillaume delbergue" <address@hidden>, 
> "alex
> bennee" <address@hidden>, "mark burton" <address@hidden>, "a rigo"
> <address@hidden>, "Frederic Konrad" <address@hidden>
> Sent: Wednesday, August 26, 2015 12:31:22 AM
> Subject: Re: [RFC 35/38] cputlb: use cpu_tcg_sched_work for tlb_flush_all
> 
> 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 <address@hidden>
> > > ---
> > >  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?

Probably nothing.  Still, I didn't have enough time to study your
cpu_tcg_sched_work patches well, and I'm terribly worried of deadlocks
here. :)  Ensuring that the CPU loop keeps running, and can always be
woken up via halt_cond, is the simplest way to avoid deadlocks.

> 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.

The other disadvantage is that you'd have to modify all TCG backends. :(

Paolo