From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaOT9-0005EY-KB for qemu-devel@nongnu.org; Mon, 29 Feb 2016 09:06:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaOT6-0005iK-Ux for qemu-devel@nongnu.org; Mon, 29 Feb 2016 09:06:39 -0500 Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]:36852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaOT6-0005i9-Kq for qemu-devel@nongnu.org; Mon, 29 Feb 2016 09:06:36 -0500 Received: by mail-wm0-x233.google.com with SMTP id n186so50931328wmn.1 for ; Mon, 29 Feb 2016 06:06:36 -0800 (PST) Sender: Paolo Bonzini References: <1456751763-24244-1-git-send-email-a.rigo@virtualopensystems.com> <56D44C8C.3050800@redhat.com> From: Paolo Bonzini Message-ID: <56D45069.8090206@redhat.com> Date: Mon, 29 Feb 2016 15:06:33 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [mttcg] cputlb: Use async tlb_flush_by_mmuidx List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: alvise rigo , Peter Maydell Cc: MTTCG Devel , Mark Burton , Claudio Fontana , QEMU Developers , Jani Kokkonen , "tech@virtualopensystems.com" , =?UTF-8?Q?Alex_Benn=c3=a9e?= , =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= On 29/02/2016 15:02, alvise rigo wrote: > > Yeah, that's the other approach -- really split the things that can > > be async and do real "wait for completion" at points which must > > synchronize. (Needs a little care since DMB is not the only such point.) > > An initial implementation that does an immediate wait-for-completion > > is probably simpler to review though, and add the real asynchrony > > later. And either way you need an API for the target to wait for > > completion. > OK, so basically being sure that the target CPU performs the flush > before executing the next TB is not enough. We need a sort of feedback > that the flush has been done before emulating the next guest > instruction. Did I get it right? That risks getting deadlocks if CPU A asks B to flush the TLB and vice versa. Using a halted state means that the VCPU thread goes through the cpus.c loop and can for example service other CPUs' TLB flush requests. Paolo