-
Notifications
You must be signed in to change notification settings - Fork 10
Fix cross-process signal delivery to EL0-preempted guests #76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1941,11 +1941,22 @@ int vcpu_run_loop(hv_vcpu_t vcpu, | |
| exit_code = 128; | ||
| running = false; | ||
| } | ||
| } else if (vexit->reason == HV_EXIT_REASON_CANCELED) { | ||
| } else if (vexit->reason == HV_EXIT_REASON_CANCELED || | ||
| vexit->reason == HV_EXIT_REASON_UNKNOWN) { | ||
|
Comment on lines
+1944
to
+1945
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Add proper comments.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Routing UNKNOWN through the same fall-through as CANCELED is broad: if HVF ever returns UNKNOWN for a genuine fault (not the SIGUSR2 race), the loop will silently retry instead of taking the } else if (vexit->reason == HV_EXIT_REASON_CANCELED ||
(vexit->reason == HV_EXIT_REASON_UNKNOWN &&
(signal_pending() ||
proc_exit_group_requested() ||
(is_main && g_timed_out)))) {Per the PR description the queued guest signal is already drained before we reach the switch, so |
||
| /* Canceled by hv_vcpus_exit(). Can be: alarm timeout, | ||
| * exit_group from another thread, or signal preemption | ||
| * (signal_queue called hv_vcpus_exit to deliver a signal | ||
| * while the guest was in a tight loop). | ||
| * | ||
| * HV_EXIT_REASON_UNKNOWN is the same event seen from the other | ||
| * side of a race: when a host signal (e.g. the SIGUSR2 used by the | ||
| * cross-process guest-signal transport) is delivered to this thread | ||
| * while it is actively executing guest code inside hv_vcpu_run, the | ||
| * run aborts with UNKNOWN instead of the clean CANCELED that | ||
| * hv_vcpus_exit() produces for a vCPU caught between runs. The | ||
| * pending guest signal has already been drained and queued, so it | ||
| * is fully deliverable -- fall through to the same handling and | ||
| * resume rather than treating it as a fatal unexpected exit. | ||
| */ | ||
| if (is_main && g_timed_out) { | ||
| /* Timeout already handled above the exception switch -- | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
P2: Treating every
HV_EXIT_REASON_UNKNOWNas cancelation can mask real hypervisor failures and cause silent retry loops when no signal is pending.Prompt for AI agents