From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9vW2-0000rX-Cn for qemu-devel@nongnu.org; Mon, 06 Jun 2016 10:28:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b9vVz-0003vx-3V for qemu-devel@nongnu.org; Mon, 06 Jun 2016 10:28:30 -0400 Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]:37169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9vVy-0003vr-Sl for qemu-devel@nongnu.org; Mon, 06 Jun 2016 10:28:27 -0400 Received: by mail-wm0-x22a.google.com with SMTP id k204so29674310wmk.0 for ; Mon, 06 Jun 2016 07:28:26 -0700 (PDT) From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Mon, 06 Jun 2016 15:28:39 +0100 Message-ID: <87a8iyie7c.fsf@linaro.org> MIME-Version: 1.0 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: Peter Maydell Cc: MTTCG Devel , KONRAD =?utf-8?B?RnI=?= =?utf-8?B?w6lkw6lyaWM=?= , Alvise Rigo , Sergey Fedorov , "Emilio G. Cota" , QEMU Developers , Mark Burton , Paolo Bonzini , "J. Kiszka" , Richard Henderson , Claudio Fontana , Peter Crosthwaite Peter Maydell writes: > On 15 April 2016 at 15:23, Alex Bennée wrote: >> This makes multi-threading the default for 32 bit ARM on x86. It has >> been tested with Debian Jessie as well as my extended KVM unit tests >> which stress the SMC and TB invalidation code. Those tests can be found >> at: >> >> https://github.com/stsquad/kvm-unit-tests/tree/mttcg/current-tests-v5 >> >> Signed-off-by: Alex Bennée >> --- >> cpus.c | 20 ++++++++++++++++---- >> 1 file changed, 16 insertions(+), 4 deletions(-) >> >> 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 >> + * - 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 >> +#else >> + /* Until memory ordering implemented things will likely break */ >> return false; >> +#endif > > No new per-host ifdef ladders, please (or per-target ifdef ladders, > either). Have some #defines for "TCG backend supports MTTCG" and > "TCG frontend supports MTTCG" which get set in some suitable per-host > and per-target header, and only enable if they're both set. Will do so. I guess the middling case of backend is strongly ordered enough to get away with partial barrier implementation at the front end should be skipped? We'll only turn on the frontend/backend support flags when: * All frontends fully express the ordering constraints to the TCG (e.g. all barriers and annotations complete) * The backend emits enough code to ensure any ordering constraint expressed in TCG ops can be satisfied. Are you happy to keep the commentary here with the default function as that is where people are likely to end up when searching? > > thanks > -- PMM -- Alex Bennée