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.
|