----- Original Message ----- > From: "Emilio G. Cota" <[email protected]> > To: "Paolo Bonzini" <[email protected]> > Cc: [email protected], [email protected], "guillaume delbergue" > <[email protected]>, "alex > bennee" <[email protected]>, "mark burton" <[email protected]>, > "a rigo" > <[email protected]>, "Frederic Konrad" <[email protected]> > 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 <[email protected]> > > > --- > > > 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
