Aaron Lindsay <aa...@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
