Philippe,
For hexagon sysemu, while internally reviewing patches to be upstreamed we
noticed that our design for a lock instruction is not quite suitable. The
k0lock instruction will halt if some other hexagon hardware CPU has already
claimed the kernel lock, only to continue executing once some CPU executes the
unlock instruction. We modeled this using a lock state enumeration member {
OWNER, WAITING, UNLOCKED } in *each* vCPU and atomically transitioning the lock
required us to have vCPU[n] write the updated lock state to vCPU[m] when
unlocking.
In context:
https://github.com/quic/qemu/blob/hexagon_sysemu_20_dec_2023/target/hexagon/op_helper.c#L1790-L1821
So instead, maybe it makes more sense to have a system device hold a single
representation of the lock's state and each vCPU can do some kind of access via
load/store and/or interrupts to/from the device? I was thinking of raising an
interrupt on the lock device at the vCPU's k0lock instruction to indicate
demand for the lock, and then the device could raise an interrupt to one of the
vCPUs when it's granted the lock. One drawback for this is that this might add
significant latency to the uncontested lock case. So I also considered doing a
load of some part of the lock device's memory that could indicate whether the
lock was available, and if available it would claim it with a store (both ld/st
while holding BQL). Only if unavailable it would halt and raise the interrupt.
Is it possible to create an address space that's independent of the true
system memory map for this use case or would we need to carve out some memory
from the existing memory map for this synthetic device? Or - do you have a
suggestion for a better approach overall?
-Brian
