RISC-V: Clear load reservations while restoring hart contexts
This is almost entirely a comment. The bug is unlikely to manifest on existing hardware because there is a timeout on load reservations, but manifests on QEMU because there is no timeout. Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
This commit is contained in:
parent
54ecb8f702
commit
18856604b3
|
@ -22,6 +22,7 @@
|
|||
|
||||
#define REG_L __REG_SEL(ld, lw)
|
||||
#define REG_S __REG_SEL(sd, sw)
|
||||
#define REG_SC __REG_SEL(sc.d, sc.w)
|
||||
#define SZREG __REG_SEL(8, 4)
|
||||
#define LGREG __REG_SEL(3, 2)
|
||||
|
||||
|
|
|
@ -98,7 +98,26 @@ _save_context:
|
|||
*/
|
||||
.macro RESTORE_ALL
|
||||
REG_L a0, PT_SSTATUS(sp)
|
||||
REG_L a2, PT_SEPC(sp)
|
||||
/*
|
||||
* The current load reservation is effectively part of the processor's
|
||||
* state, in the sense that load reservations cannot be shared between
|
||||
* different hart contexts. We can't actually save and restore a load
|
||||
* reservation, so instead here we clear any existing reservation --
|
||||
* it's always legal for implementations to clear load reservations at
|
||||
* any point (as long as the forward progress guarantee is kept, but
|
||||
* we'll ignore that here).
|
||||
*
|
||||
* Dangling load reservations can be the result of taking a trap in the
|
||||
* middle of an LR/SC sequence, but can also be the result of a taken
|
||||
* forward branch around an SC -- which is how we implement CAS. As a
|
||||
* result we need to clear reservations between the last CAS and the
|
||||
* jump back to the new context. While it is unlikely the store
|
||||
* completes, implementations are allowed to expand reservations to be
|
||||
* arbitrarily large.
|
||||
*/
|
||||
REG_L a2, PT_SEPC(sp)
|
||||
REG_SC x0, a2, PT_SEPC(sp)
|
||||
|
||||
csrw CSR_SSTATUS, a0
|
||||
csrw CSR_SEPC, a2
|
||||
|
||||
|
|
Loading…
Reference in New Issue