qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] TCG baremetal tests repo


From: Frederic Konrad
Subject: Re: [Qemu-devel] TCG baremetal tests repo
Date: Thu, 25 Jun 2015 18:01:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]