From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bp0so-0003ZB-Gr for qemu-devel@nongnu.org; Tue, 27 Sep 2016 18:29:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bp0sl-0002OH-Ao for qemu-devel@nongnu.org; Tue, 27 Sep 2016 18:29:50 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:58399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bp0si-0002Cn-Vj for qemu-devel@nongnu.org; Tue, 27 Sep 2016 18:29:47 -0400 Date: Tue, 27 Sep 2016 18:29:35 -0400 From: "Emilio G. Cota" Message-ID: <20160927222935.GA21144@flamenco> References: <87wpk8k3dn.fsf@linaro.org> <87eg677k2x.fsf@linaro.org> <5d48957b-780b-aa9c-7061-cba6808909b4@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d48957b-780b-aa9c-7061-cba6808909b4@redhat.com> Subject: Re: [Qemu-devel] Making cputlb.c operations safe for MTTCG List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Alex =?iso-8859-1?Q?Benn=E9e?= , MTTCG Devel , QEMU Developers , a.rigo@virtualopensystems.com, Sergey Fedorov , Richard Henderson , Frederic Konrad On Tue, Sep 27, 2016 at 18:16:45 +0200, Paolo Bonzini wrote: > Anyhow, the next step is to merge either cmpxchg-based atomics > or iothread-free single-threaded TCG. Either will do. :) > > I think that even iothread-free single-threaded TCG requires this > TLB stuff, because the iothread's address_space_write (and hence > invalidate_and_set_dirty) can race against the TCG thread's > code generation. What's a quick-and-dirty way to disable the fast-path TLB lookups? Alex: you told me the monitor has an option for this, but I can't find it. I'm looking for something that'd go in tcg/i386 to simply bypass the fast path. Forcing the slow TLB lookup would be an easy way to then implement a per-TLB seqlock. I think TLB corruption might explain the crashes I see when booting Ubuntu in a many-core guest (running on a many-core host). Thanks, Emilio