[Qemu-devel] Atomic instruction.

[Frederic Konrad]

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