On 14/10/26 06:13, Brian Cain wrote:
On 10/13/2026 10:01 PM, Philippe Mathieu-Daudé wrote:
On 9/10/26 21:25, Brian Cain wrote:
Set PC to the tlblock instruction and leave the CPU loop when the
lock is
contended. This retries tlblock after ownership is passed and prevents
execution without the lock.
Signed-off-by: Brian Cain <[email protected]>
---
target/hexagon/hex_mmu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/target/hexagon/hex_mmu.c b/target/hexagon/hex_mmu.c
index bdcfa057c21..b9fab949d0f 100644
--- a/target/hexagon/hex_mmu.c
+++ b/target/hexagon/hex_mmu.c
@@ -12,6 +12,7 @@
#include "system/cpus.h"
#include "internal.h"
#include "exec/cpu-interrupt.h"
+#include "accel/tcg/cpu-loop.h"
#include "cpu_helper.h"
#include "exec/cputlb.h"
#include "hex_mmu.h"
@@ -185,11 +186,14 @@ void hex_tlb_lock(CPUHexagonState *env)
env->next_PC += 4;
CPUState *cs = env_cpu(env);
cpu_interrupt(cs, CPU_INTERRUPT_HALT);
Pre-existing apparently, is CPU_INTERRUPT_HALT appropriate?
/*
* External hardware interrupt pending.
* This is typically used for interrupts from devices.
*/
#define CPU_INTERRUPT_HARD 0x0002
or is there a better match from "exec/cpu-interrupt.h" definitions?
I think CPU_INTERRUPT_HALT is appropriate. _HARD is suitable for an
external (maskable) interrupt. The signal we need here is one that will
cause us to stop executing instructions while pending on the lock.
OK, we are good then :)
