Add metric for erroneous vCPU kicks from stale cancellations

[Copilot]

Erroneous vCPU kicks can occur when cancellation arrives after its target call completes, kicking the next call's vCPU, which immediately re-enters since cancellation wasn't requested for it. This can happen on both Linux and Windows platforms.

Changes

• Added METRIC_ERRONEOUS_VCPU_KICKS counter in metrics/mod.rs
• Incremented when HyperlightExit::Cancelled() received but !cancel_requested && !debug_interrupted

Ok(HyperlightExit::Cancelled()) => {
    if !cancel_requested && !debug_interrupted {
        metrics::counter!(METRIC_ERRONEOUS_VCPU_KICKS).increment(1);
        continue;  // Stale cancellation, retry
    }
    // ... handle actual cancellation
}

Scenarios Tracked

This metric tracks erroneous vCPU kicks that can occur in two scenarios:

1. Linux: A signal from a previous guest call arrives late and interrupts a new call
2. Windows: WHvCancelRunVirtualProcessor is called right after vCPU exits but RUNNING_BIT is still true, canceling the next vCPU run (which is immediately retried since cancellation was not requested)

This provides visibility into stale cancellation frequency as discussed in #1024.

• Fixes Add a metric for tracking erroneous vCPU kicks #1027

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add a metric for tracking erroneous vCPU kicks</issue_title>
<issue_description>If a signal is delivered very late as a result of calling kill(), it can interrupt a guest call that was not intended to be cancelled. This results in the vcpu getting "kicked", but then re-enters the guest VM immediately because the new call was not intended to be cancelled. It would be good to track how much this happens.

See #1024 (comment) for original comment</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Add a metric for tracking erroneous vCPU kicks #1027

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[ludfjig]

@copilot It can also happen on windows in the small gap where WHvCancelRunVirtualProcessor is called right after vcpu already exited but RUNNING_BIT is still true. This will cancel the next vcpu run (but it be immediately be retried since cancellation was probably not requested). Please update the comments to reflect this scenario in addition to the already mentioned stale signals

[Copilot]

@copilot It can also happen on windows in the small gap where WHvCancelRunVirtualProcessor is called right after vcpu already exited but RUNNING_BIT is still true. This will cancel the next vcpu run (...

Updated the comments in both metrics/mod.rs and hypervisor/mod.rs to include the Windows scenario where WHvCancelRunVirtualProcessor is called right after vCPU exits but RUNNING_BIT is still true. Commit: 4cac386