Re: plugins: Missing Store Exclusive Memory Accesses

["Alex Bennée" <alex.bennee@linaro.org>]

Aaron Lindsay <aaron@os.amperecomputing.com> writes:

> Hello,
>
> I recently noticed that the plugin interface does not appear to be
> emitting callbacks to functions registered via
> `qemu_plugin_register_vcpu_mem_cb` for AArch64 store exclusives. This
> would include instructions like `stxp  w16, x2, x3, [x4]` (encoding:
> 0xc8300c82). Seeing as how I'm only running with a single CPU, I don't
> see how this could be due to losing exclusivity after the preceding
> `ldxp`.

The exclusive handling is a bit special due to the need to emulate it's
behaviour using cmpxchg primitives.

>
> In looking at QEMU's source, I *think* this is because the
> `gen_store_exclusive` function in translate-a64.c is not making the same
> calls to `plugin_gen_mem_callbacks` & company that are being made by
> "normal" stores handled by functions like `tcg_gen_qemu_st_i64` (at
> least in my case; I do see some code paths under `gen_store_exclusive`
> call down into `tcg_gen_qemu_st_i64` eventually, but it appears not all
> of them do?).

The key TCG operation is the cmpxchg which does the effective store. For
-smp 1 we should use normal ld and st tcg ops. For > 1 it eventually
falls to tcg_gen_atomic_cmpxchg_XX which is a helper. That eventually
ends up at:

  atomic_trace_rmw_post

which should be where things are hooked.

> Does my initial guess check out? And, if so, does anyone have insight
> into how to fix this issue most cleanly/generically? I suspect if/when I
> debug my particular case I can discover one code path to fix, but I'm
> wondering if my discovery may be part of a larger class of cases which
> fell through the cracks and ought to be fixed together.

Have you got simple example of a test case?

>
> Thanks for any help,
>
> Aaron


-- 
Alex Bennée