8.11 PAL and LL/SC Reservations

<< Click to Display Table of Contents >>

Navigation:  ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 8 - PAL and Privileged Boundary >

8.11 PAL and LL/SC Reservations

LL/SC operations must never span a privileged boundary. A reservation created in non-PAL execution cannot survive entry into PAL mode, exit from PAL mode, exception delivery, interrupt delivery, or context switches. This is a fundamental Alpha architectural rule and is mandatory for correctness.

 

8.11.1 Why Reservations Cannot Cross PAL Boundaries

 

LL/SC relies on optimistic reservations tied to CPU execution context, memory ordering assumptions, and cache coherency state. PAL transitions break all three: execution context changes, ordering is enforced (full serialization), pipeline state is flushed, and privilege level changes. Allowing reservations to survive PAL entry would permit privileged code to commit untrusted atomic sequences, user code to observe privileged memory ordering, and stale reservations to succeed incorrectly.

 

8.11.2 Clearing Rules

 

In EMulatR, LL/SC reservations are cleared unconditionally on: CALL_PAL entry, HW_REI exit, exception delivery, interrupt delivery, context switch, and certain serialization barriers (EXCB, MB where required). This applies to all CPUs independently. Reservation tracking lives in GuestMemory (via ReservationManager), not in execution boxes, ensuring global visibility and centralized invalidation.

 

8.11.3 Example Scenario

 

; User Mode:

LDL_L R1, [X] ; Reservation created

CALL_PAL 0xNN ; Enter PAL → reservation cleared

 

; PAL Mode:

... ; Privileged work

HW_REI ; Return to user → reservation cleared again

 

; User Mode:

STL_C R1, [X] ; MUST FAIL (reservation was cleared)

 

Even if no other CPU touched the cache line, the store-conditional must fail because the reservation was cleared on PAL entry.

 

See Also: 5.11 Load-Locked / Store-Conditional (LL/SC); 6.12 Interaction with LL/SC