From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z89av-00049L-RU for qemu-devel@nongnu.org; Thu, 25 Jun 2015 12:01:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z89ar-000411-Nx for qemu-devel@nongnu.org; Thu, 25 Jun 2015 12:01:41 -0400 Received: from greensocs.com ([193.104.36.180]:51492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z89ar-000401-6i for qemu-devel@nongnu.org; Thu, 25 Jun 2015 12:01:37 -0400 Message-ID: <558C25D9.80300@greensocs.com> Date: Thu, 25 Jun 2015 18:01:29 +0200 From: Frederic Konrad MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] TCG baremetal tests repo List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Spyridakis , mttcg@listserver.greensocs.com, Mark Burton Cc: =?UTF-8?B?QWxleCBCZW5uw6ll?= , QEMU Developers , Alvise Rigo On 22/06/2015 12:54, Alexander Spyridakis wrote: > Hello all, > > You can find the latest tcg atomic test payload in the following repo: > > git clone https://git.virtualopensystems.com/dev/tcg_baremetal_tests.git > > You also need an arm baremetal cross-compiler like arm-none-gnueabi- > (arm) and the usual aarch64-linux-gnu- (arm64). Due to a PSCI bug in > the current multithreading tcg repo, the atomic test was modified to > work also on the vexpress machine model. > > To run it: > > make vexpress (or virt/virt64 for other targets) > > ../mttcg/arm-softmmu/qemu-system-arm -nographic -M vexpress-a15 > -kernel build-vexpress/image-vexpress.axf -smp 4 > > On my machine it takes around 30 seconds for one run of the test and > the results vary from as low as 5 to 30 errors per vCPU per 10 million > iterations (no errors with KVM). It is also very interesting to note, > that the current test finishes faster on upstream qemu than > multithreaded qemu. > > Best regards. Hi, I just tested this with vexpress, seems ATOMIC is not defined by default it uses: void non_atomic_lock(int *lock_var) { while (*lock_var != 0); *lock_var = 1; } void non_atomic_unlock(int *lock_var) { *lock_var = 0; } instead of: void atomic_lock(int *lock_var) { while (__sync_lock_test_and_set(lock_var, 1)); } void atomic_unlock(int *lock_var) { __sync_lock_release(lock_var); } It doesn't cause any errors upstream but a lot on mttcg and mttcg is faster in this case. I don't have any error when I use ATOMIC like this: diff --git a/helpers.h b/helpers.h index b5810ad..427659f 100644 --- a/helpers.h +++ b/helpers.h @@ -36,13 +36,8 @@ #define SYS_CFGCTR_WRITE 0x40000000 #define SYS_CFG_SHUTDOWN 0x00800000 -#ifdef ATOMIC #define LOCK atomic_lock #define UNLOCK atomic_unlock -#else -#define LOCK non_atomic_lock -#define UNLOCK non_atomic_unlock -#endif int online_cpus; int global_lock; but it's slower than upstream which I think is normal. We can have two CPUs fighting for the lock in mttcg but not in upstream as VCPUs doesn't run at the same time. Fred