From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUOXD-0004nC-DO for qemu-devel@nongnu.org; Tue, 25 Aug 2015 20:25:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUOX9-0007Cj-2m for qemu-devel@nongnu.org; Tue, 25 Aug 2015 20:25:47 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:33771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUOX8-0007CL-Rm for qemu-devel@nongnu.org; Tue, 25 Aug 2015 20:25:43 -0400 Date: Tue, 25 Aug 2015 20:25:36 -0400 (EDT) From: Paolo Bonzini Message-ID: <400055427.19003548.1440548736680.JavaMail.zimbra@redhat.com> In-Reply-To: <20150825223122.GG29063@flamenco> References: <1440375847-17603-1-git-send-email-cota@braap.org> <1440375847-17603-36-git-send-email-cota@braap.org> <55DA737D.6040509@redhat.com> <20150825223122.GG29063@flamenco> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 35/38] cputlb: use cpu_tcg_sched_work for tlb_flush_all List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Emilio G. Cota" Cc: mttcg@greensocs.com, mark burton , a rigo , qemu-devel@nongnu.org, guillaume delbergue , alex bennee , Frederic Konrad ----- Original Message ----- > From: "Emilio G. Cota" > To: "Paolo Bonzini" > Cc: qemu-devel@nongnu.org, mttcg@greensocs.com, "guillaume delbergue" , "alex > bennee" , "mark burton" , "a rigo" > , "Frederic Konrad" > 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 > > > --- > > > 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