On 30 August 2015 at 20:29, Timothy E Baldwin
<t.e.baldwi...@members.leeds.ac.uk> wrote:
> Implemented ARM __kernel_memory_barrier using GCC/clang
> builtin __sync_synchronize().
>
> Signed-off-by: Timothy Edward Baldwin <t.e.baldwi...@members.leeds.ac.uk>
> ---
>  linux-user/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 2c9658e..f4b81b1 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -531,7 +531,7 @@ do_kernel_trap(CPUARMState *env)
>
>      switch (env->regs[15]) {
>      case 0xffff0fa0: /* __kernel_memory_barrier */
> -        /* ??? No-op. Will need to do better for SMP.  */
> +        __sync_synchronize();
>          break;

I don't think this is correct, because this kernel usermode
page entrypoint is just "do a DMB, however that works on
this CPU's ARM architecture flavour". We implement DMB
in target-arm/ as a no-op, and so no-op here is also the
right thing.

This does mean that we potentially have problems with
multithreaded guests, but those don't currently work
anyway. Fixing this requires a wider effort to implement
memory barriers properly when we have multiple threads
running QEMU guest CPUs at once, which may come out of
the current MTTCG efforts.

thanks
-- PMM

Reply via email to