Re: [PATCH 4/6] target/hexagon: halt on tlblock when the TLB lock is contended

[Brian Cain]

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 <brian.c...@oss.qualcomm.com>
---
  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.



+            cpu_loop_exit(cs);

This call makes sense otherwise.

              return;
          }