openvmm: a gdb Break on a paused VM changes the partition's saved halt reason #1374

With the gdb stub (--gdb; the gdb feature is on by default in the openvmm crate) and a debugger attached, a DebugRequest::Break sent while the VM is paused records HaltReason::DebugBreak on the stopped partition unit. The VM never ran, but a save taken after the Break differs from one taken before it, and restoring the later snapshot starts the VM halted on that debug break. Only a host debugger session reaches this; the guest cannot.

Reproduction

Start a partition unit, stop it, and save: the saved state has no halt reason. Send DebugRequest::Break, let the run loop handle the halt event, and save again. Expected: the same saved state. Actual: it carries DebugBreak. A unit test of the partition unit shows this; it is not attached, since there is no patch.

Cause

PartitionUnitRunner::handle_gdb halts the VPs whatever the unit's state:

// vmm_core/src/partition_unit/debug.rs
DebugRequest::Break => {
    tracing::debug!("debug break requested");
    self.vp_set.halt(HaltReason::DebugBreak { vp: None });
}

The run loop's halt arm stops the VPs again, which changes nothing while paused, and handle_halt then records the reason in halt_reason, which save serializes:

// vmm_core/src/partition_unit.rs
Event::Halt(reason) => {
    // ...
    self.vp_set.stop().await;
    self.handle_halt(reason).await;
}

Fix

No patch is attached; the debugger's semantics need a decision:

• Ignore Break while the unit is stopped. The VPs are already stopped, but the debugger gets no stop report for its Break.
• Defer Break until the next resume. The request is kept, and the VM halts for the debugger as soon as it resumes.
• Allow the change, and document that a snapshot taken during a debugger session may carry the halt.