Comments please….
Choices for Atomic instructions:
The current approach (for ARM at least) for Ld and St exclusive inside Qemu
simply records the address and the value that atomic read instructions attempt
to read from. When an atomic write happens, it checks the value and address
remain the same, otherwise it fails.
This just doesn’t match the architecturally defined functionality. For
instance, a write will succeed if another thread intervenes with a write at the
same address with the same (old) value.
However - for most people, most of the time, this semantic seems to work.
One proposal is ‘simply’ to add a mutex around this code, such that
multi-threaded TCG will correctly update/read these saved address/values.
This _should_ maintain the status-quo. Things that were broken before will
remain broken, nothing new should break. The concern is that the fact that the
TCG was previously uni-threaded MAY be masking problems with this code that we
are not taking into account.
A second proposal is to somehow re-use the dirty bit mechanism.
However - the dirty bit approach seems to be too corse grained (per
page), and (I think) only covers writes, which seems like a limitation which is
not ideal….
A third proposal is to mark pages as IO when a ld/st ex is performed to them.
Then to augment the memory API to indicate that a ld/st ex is in hand, allowing
the memory chain to decide if it should allow the write or cause a fault. This
would seem to be the closest approach to the real H/W. However it means marking
pages as IO (which could cause us issues if there was code on that page?, or
slow things down) - and it means adding to the memory API.
Cheers
Mark.
+44 (0)20 7100 3485 x 210
+33 (0)5 33 52 01 77x 210
+33 (0)603762104
mark.burton
<applewebdata://22184F84-4051-4135-B094-40936F803859/www.greensocs.com>
