Hi everybody,
We are experimenting with multi-core QEMU. We have Multiple QEMU cores
running
on multiple host threads and we are now looking at the issue of ‘atomic’
instructions.
Our initial thought was to push some sort of set of flags out to the memory
chain (eg: ATOMIC or NORMAL much as the H/W would do). However, this is
a lot of
changes and there seems to be a choice of a number of different ways of
doing
this.
We think the best approach overall is to leave the current mechanisms for
guaranteeing the functionality of e.g. load/store exclusive in place.
That is to say, right now, for instance for ARM, QEMU stores the addr/val of
loads, and compare them to ensure they have not been changed on store.
Effectively it does a load-compair-store for the store.
This is a ‘belt and braces’ implementation of the H/W, but it’s good.
I believe it is valid to say that - so long as each core can guarantee
that the
‘load-compair-store’ is somehow atomic, then it is perfectly
satisfactory for
each QEMU core to hold it’s own value for the ‘old value’ etc, and this
mechanism will still work.
The issue will only be to ensure that the load-compair-store is atomic - and
only in the ‘store exclusive’.
Overall, this mechanism does not actually mirror the hardware we are
modelling,
so overall we think it would be easier and more re-usable to provide two new
OP’s in the TCG, one to lock a mutex, one to release it.
For QEMU’s on a single host thread, the implementation of these can be
empty,
and generate no code.
For QEMU’s that are intended to run on multiple host threads, we can
have code
that calls out to a helper that will take or release this mutex.
Clearly we are a long way from a patch set that would be helpful
upstream, but
we would very much appreciate feedback on this approach.
Thanks,
Fred