You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/cancellation.md
+8-9Lines changed: 8 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,14 +12,14 @@ Hyperlight provides a mechanism to forcefully interrupt guest execution through
12
12
13
13
The `LinuxInterruptHandle` uses a packed atomic u64 to track execution state:
14
14
15
-
-**state (AtomicU64)**: Packs two bits:
15
+
-**state (AtomicU64)**: Packs three bits:
16
+
-**Bit 2 (DEBUG_INTERRUPT_BIT)**: Set when debugger interrupt is requested (gdb feature only)
16
17
-**Bit 1 (RUNNING_BIT)**: Set when vCPU is actively running in guest mode
17
18
-**Bit 0 (CANCEL_BIT)**: Set when cancellation has been requested via `kill()`
18
19
-**tid (AtomicU64)**: Thread ID where the vCPU is running
19
-
-**debug_interrupt (AtomicBool)**: Set when debugger interrupt is requested (gdb feature only)
20
20
-**dropped (AtomicBool)**: Set when the corresponding VM has been dropped
21
21
22
-
The packed state enables atomic reads of both RUNNING_BITand CANCEL_BIT simultaneously via `get_running_and_cancel()`. Within a single `VirtualCPU::run()` call, the CANCEL_BIT remains set across vcpu exits and re-entries (such as when calling host functions), ensuring cancellation persists until the guest call completes. However, `clear_cancel()` resets the CANCEL_BIT at the beginning of each new guest function call (specifically in `MultiUseSandbox::call`, before `VirtualCPU::run()` is called), preventing cancellation requests from affecting subsequent guest function calls.
22
+
The packed state enables atomic reads of RUNNING_BIT, CANCEL_BIT and DEBUG_INTERRUPT_BIT simultaneously via `get_running_cancel_debug()`. Within a single `VirtualCPU::run()` call, the CANCEL_BIT remains set across vcpu exits and re-entries (such as when calling host functions), ensuring cancellation persists until the guest call completes. However, `clear_cancel()` resets the CANCEL_BIT at the beginning of each new guest function call (specifically in `MultiUseSandbox::call`, before `VirtualCPU::run()` is called), preventing cancellation requests from affecting subsequent guest function calls.
23
23
24
24
### Signal Mechanism
25
25
@@ -176,9 +176,9 @@ sequenceDiagram
176
176
- Ensures all writes before `kill()` are visible when vCPU thread checks `is_cancelled()` with `Acquire`
177
177
178
178
2.**Send Signals**: Enter retry loop via `send_signal()`
179
-
- Atomically load both runningand cancel flags via `get_running_and_cancel()` with `Acquire` ordering
180
-
- Continue if `running=true AND cancel=true` (or `running=true AND debug_interrupt=true` with gdb)
181
-
- Exit loop immediately if `running=false OR cancel=false`
179
+
- Atomically load running, cancel and debug flags via `get_running_cancel_debug()` with `Acquire` ordering
180
+
- Continue if `running=true AND cancel=true` (or `running=true AND debug=true` with gdb)
181
+
- Exit loop immediately if `running=false OR (cancel=false AND debug=false)`
182
182
183
183
3.**Signal Delivery**: Send `SIGRTMIN+offset` via `pthread_kill`
184
184
- Signal interrupts the `ioctl` that runs the vCPU, causing `EINTR`
0 commit comments