Re: plugins: Missing Store Exclusive Memory Accesses

[Alex Bennée]

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

> On Oct 21 13:28, Alex Bennée wrote:
>> It's a bit clearer if you use the contrib/execlog plugin:
>> 
>>   ./qemu-aarch64 -plugin contrib/plugins/libexeclog.so -d plugin  
>> ./tests/tcg/aarch64-linux-user/stxp
>> 
>>   0, 0x400910, 0xf9800011, "prfm pstl1strm, [x0]
>>   0, 0x400914, 0xc87f4410, "ldxp x16, x17, [x0]", load, 0x55007fffd0, load, 
>> 0x55007fffd8 
>>   0, 0x400918, 0xc8300c02, "stxp w16, x2, x3, [x0]", load, 0x55007fffd0, 
>> load, 0x55007fffd8, store, 0x55007fffd0, store, 0x55007fffd8 
>>   0, 0x40091c, 0xf1000652, "subs x18, x18, #1"
>>   0, 0x400920, 0x54000040, "b.eq #0x400928"
>>   0, 0x400924, 0x17fffffb, "b #0x400910"
<snip>
>> 
>> Although you can see stxp looks a bit weird on account of the loads it
>> does during the cmpxchng. So consider me stumped. The only thing I can
>> thing of next is to see how closely I can replicate your build
>> environment.
>
> I apologize, I had apparently gotten farther behind upstream than I
> realized since originally encountering this. I tried the latest upstream
> code and am now able to observe the same thing as you. Somewhere between
> v6.1.0 and now, the original issue I reported has been resolved.
>
> However, I am not sure reporting loads for a store exclusive makes sense
> to me here, either. My understanding is that the stxp needs to check if
> it still has exclusive access and QEMU's implementation results in the
> extra loads, but I would expect that the plugin interface would only
> report architectural loads.

Yes this is an anomaly. It's not reporting all loads and stores because
there are accesses to cpu_exclusive_addr and cpu_exclusive_val which we
use to simulate the exclusivity check. However we don't currently have a
way to signal to the TCG that a cmpxchg is only being done to simulate a
store.

I guess we need to either signal the helper someway to avoid calling
atomic_trace_rmw_post and call atomic_trace_st_post instead. Ideally we
could signal this in metadata somehow (although I suspect adding
something to MemOpIdx might be too ugly). The alternative would be
defining another series of cmpxchg helpers that did this.

Looking at the code also reminds me that we need to excise the broken
memory trace code.

> Is there any obvious way to omit the loads from the plugin interface
> here?
>
> -Aaron


-- 
Alex Bennée