From: Jan Kiszka <[email protected]> This makes it clearer why we have no explicit memory barrier in the spin_lock/unlock implementation, in contrast to the ARMv7 version.
Based on research by Peng Fan. Signed-off-by: Jan Kiszka <[email protected]> --- hypervisor/arch/arm64/include/asm/spinlock.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/hypervisor/arch/arm64/include/asm/spinlock.h b/hypervisor/arch/arm64/include/asm/spinlock.h index de814bc2..ac7063b7 100644 --- a/hypervisor/arch/arm64/include/asm/spinlock.h +++ b/hypervisor/arch/arm64/include/asm/spinlock.h @@ -30,6 +30,13 @@ typedef struct { u16 next; } spinlock_t __attribute__((aligned(4))); +/* + * According to ARMv8 DDI 0487D.a, B2-108: + * "The Load-Acquire, Load-AcquirePC, and Store-Release instructions + * can remove the requirement to use the explicit DMB instruction." + * + * So no need explicit memory_barrier bound with spin_lock/unlock + */ static inline void spin_lock(spinlock_t *lock) { unsigned int tmp; @@ -61,6 +68,9 @@ static inline void spin_lock(spinlock_t *lock) : "memory"); } +/* + * See spin_lock: This implementation implies a memory barrier. + */ static inline void spin_unlock(spinlock_t *lock) { asm volatile( -- 2.16.4 -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/c16ed30bd64efc9d7a30745c333de9adc80b4a13.1577125789.git.jan.kiszka%40web.de.
