----- Original Message ----- > From: "Emilio G. Cota" <c...@braap.org> > To: "Paolo Bonzini" <pbonz...@redhat.com> > Cc: qemu-devel@nongnu.org, mt...@greensocs.com, "guillaume delbergue" > <guillaume.delber...@greensocs.com>, "alex > bennee" <alex.ben...@linaro.org>, "mark burton" <mark.bur...@greensocs.com>, > "a rigo" > <a.r...@virtualopensystems.com>, "Frederic Konrad" <fred.kon...@greensocs.com> > 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 <c...@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?
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
