From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9rcz-0006Cd-67 for qemu-devel@nongnu.org; Mon, 06 Jun 2016 06:19:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b9rcu-0006N3-4U for qemu-devel@nongnu.org; Mon, 06 Jun 2016 06:19:24 -0400 Received: from mail-lf0-x244.google.com ([2a00:1450:4010:c07::244]:33591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9rct-0006Mz-Rr for qemu-devel@nongnu.org; Mon, 06 Jun 2016 06:19:20 -0400 Received: by mail-lf0-x244.google.com with SMTP id w16so12991130lfd.0 for ; Mon, 06 Jun 2016 03:19:19 -0700 (PDT) References: <87eg8aithe.fsf@linaro.org> From: Sergey Fedorov Message-ID: <57554E25.9050405@gmail.com> Date: Mon, 6 Jun 2016 13:19:17 +0300 MIME-Version: 1.0 In-Reply-To: <87eg8aithe.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC v1 12/12] cpus: default MTTCG to on for 32 bit ARM on x86 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: mttcg@listserver.greensocs.com, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, cota@braap.org, qemu-devel@nongnu.org, mark.burton@greensocs.com, pbonzini@redhat.com, jan.kiszka@siemens.com, rth@twiddle.net, peter.maydell@linaro.org, claudio.fontana@huawei.com, Peter Crosthwaite On 06/06/16 11:58, Alex Bennée wrote: > Sergey Fedorov writes: > >> On 15/04/16 17:23, Alex Bennée wrote: >>> diff --git a/cpus.c b/cpus.c >>> index 860e2a9..daa92c7 100644 >>> --- a/cpus.c >>> +++ b/cpus.c >>> @@ -171,12 +171,24 @@ opts_init(tcg_register_config); >>> >>> static bool default_mttcg_enabled(void) >>> { >>> - /* >>> - * TODO: Check if we have a chance to have MTTCG working on this guest/host. >>> - * Basically is the atomic instruction implemented? Is there any >>> - * memory ordering issue? >>> + /* Checklist for enabling MTTCG on a given frontend/backend combination >>> + * >>> + * - Are atomics correctly modelled for an MTTCG environment >> - Are cross-CPU manipulations safe (e.g. TLB invalidation/flush from >> target helper) >> - Are TCG context manipulations safe (e.g. TB invalidation from target >> helper) > OK > >>> + * - If the backend is weakly ordered >>> + * - has the front-end implemented explicit memory ordering ops >>> + * - does the back-end generate code to ensure memory ordering >>> */ >>> +#if defined(__i386__) || defined(__x86_64__) >>> + /* x86 backend is strongly ordered which helps a lot */ >>> + #if defined(TARGET_ARM) >>> + return true; >>> + #else >>> + return false; >>> + #endif >> Is it okay to indent preprocessor lines this way? I think preprocessor >> lines are better to stand out from regular code and could be indented >> like this: >> >> #if defined(__foo__) >> # if defined(BAR) >> /* ... */ >> # else >> /* ... */ >> # endif >> #else >> /* ... */ >> #endif > To be honest I was expecting more push-back on this because it is such > an ugly way of solving the problem and expressing what a default on > means. I could be okay as long as there are only a few options. We could also put here some generic tests like strong/weak ordering checks and introduce target- and host-specific functions which can tell us if we should ever try enabling MTTCG for them. Kind regards, Sergey