From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4te4-0003Wr-FR for qemu-devel@nongnu.org; Thu, 10 Nov 2016 13:00:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4te1-0007Yo-D7 for qemu-devel@nongnu.org; Thu, 10 Nov 2016 13:00:16 -0500 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:36527) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4te1-0007YM-6w for qemu-devel@nongnu.org; Thu, 10 Nov 2016 13:00:13 -0500 Received: by mail-wm0-x22d.google.com with SMTP id g23so56294280wme.1 for ; Thu, 10 Nov 2016 10:00:12 -0800 (PST) References: <20161109145748.27282-1-alex.bennee@linaro.org> <20161109145748.27282-14-alex.bennee@linaro.org> <87wpgcmomy.fsf@gmail.com> <87eg2j8g7c.fsf@linaro.org> <2f256c7e-cd92-0678-db23-e269203a7164@twiddle.net> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <2f256c7e-cd92-0678-db23-e269203a7164@twiddle.net> Date: Thu, 10 Nov 2016 18:00:10 +0000 Message-ID: <87a8d78bbp.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v6 13/19] cputlb: atomically update tlb fields used by tlb_reset_dirty List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Pranith Kumar , pbonzini@redhat.com, qemu-devel@nongnu.org, mttcg@greensocs.com, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, cota@braap.org, nikunj@linux.vnet.ibm.com, mark.burton@greensocs.com, jan.kiszka@siemens.com, serge.fdrv@gmail.com, peter.maydell@linaro.org, claudio.fontana@huawei.com, Peter Crosthwaite Richard Henderson writes: > On 11/10/2016 05:14 PM, Alex Bennée wrote: >> Even worse than that we trip up the atomic.h QEMU_BUILD_BUG_ON with the >> atomic_cmpxchg. Now I believe we can use atomic_cmpxchg__nocheck without >> too much issue on x86 but we'll need to #ifdef it on detection of wide >> atomics. > > You've already got CONFIG_ATOMIC64. And what's the fallback? I'm going to re-factor cputlb a bit so all the TLB read and write's can be done in helper functions so I don't scatter stuff around too much. I was thinking something like: #ifdef CONFIG_ATOMIC64 .. as usual .. #else assert(!parallel_cpus) .. non atomic update .. #endif > We ought not be enabling mttcg for 32-bit host and 64-bit guest at all. But > that doesn't help much here, where we're otherwise guest width > agnostic. Hmm well the most common case (any guest on x86) should work. Currently the default mttcg code in cpus.c works when: #if defined(CONFIG_MTTCG_TARGET) && defined(CONFIG_MTTCG_HOST) I should probably expand that to default to false in the case of (sizeof target_ulong > sizeof void *) when we don't have CONFIG_ATOMIC64. Then if the user does force mttcg on they will quickly get an assert although maybe we want to report that in a nicer way? > > > r~ -- Alex Bennée