From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad1cR-0006o9-0j for qemu-devel@nongnu.org; Mon, 07 Mar 2016 15:19:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad1cM-0001ca-9a for qemu-devel@nongnu.org; Mon, 07 Mar 2016 15:19:06 -0500 Received: from mail-wm0-x236.google.com ([2a00:1450:400c:c09::236]:37045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad1cL-0001cP-TK for qemu-devel@nongnu.org; Mon, 07 Mar 2016 15:19:02 -0500 Received: by mail-wm0-x236.google.com with SMTP id p65so884878wmp.0 for ; Mon, 07 Mar 2016 12:19:01 -0800 (PST) References: <1456751763-24244-1-git-send-email-a.rigo@virtualopensystems.com> <56D44C8C.3050800@redhat.com> <56D45069.8090206@redhat.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Mon, 07 Mar 2016 20:18:59 +0000 Message-ID: <8737s2ujm4.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 Cc: MTTCG Devel , Peter Maydell , Claudio Fontana , Mark Burton , QEMU Developers , Paolo Bonzini , Jani Kokkonen , "tech@virtualopensystems.com" , KONRAD =?utf-8?B?RnLDqWTDqXJpYw==?= alvise rigo writes: > A small update on this. I have a working implementation of the "halted > state" mechanism for waiting all the pending flushes to be completed. > However, the way I'm going back to the cpus.c loop (the while(1) in > qemu_tcg_cpu_thread_fn) is a bit convoluted. In the case of the TLB ops > that always end the TB, a simple cpu_exit() allows me to go back to the > main loop. I think in this case we can also use the cpu_loop_exit(), though > making the code a bit more complicated since the PC would require some > adjustments. > > I wanted then to apply the same "halted state" to the LoadLink helper, > since also this one might cause some flush requests. In this case, we can > not just call cpu_loop_exit() in that the guest code would miss the > returned value. Forcing the LDREX instruction to also end the TB through an > empty 'is_jmp' condition did the trick allowing once again to use > cpu_exit(). Is there another better solution? Have you looked at Emilio's tree where he replaced the async_safe_work mechanism with a mechanism to do the work in the vCPU run loop but halt all other vCPUs first? > > Thank you, > alvise > > On Mon, Feb 29, 2016 at 3:18 PM, alvise rigo > wrote: > >> I see the risk. I will come back with something and let you know. >> >> Thank you, >> alvise >> >> On Mon, Feb 29, 2016 at 3:06 PM, Paolo Bonzini >> wrote: >> > >> > >> > 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 >> -- Alex Bennée