WHP: releasing file mappings after deleting partition in WhpVm::Drop

[ludfjig]

Keep mapped-file views alive while WHP may still reference them. With surrogate processes disabled (HYPERLIGHT_MAX_SURROGATES=0), WHvMapGpaRange uses the host view directly. Releasing that view during VM teardown leaves an active GPA mapping backed by an invalid virtual address.

This is a defensive change, I don't know of any current impact

[Copilot]

Pull request overview

Reorders WHP teardown so mapped-file views remain valid until the partition is deleted.

Changes:

• Moves mapped-file cleanup after WHvDeletePartition.
• Prevents invalid host addresses during teardown.
• Moderate issue: failed partition deletion may still leave active mappings before views are released.

Suppressed comments (1)

src/hyperlight_host/src/hypervisor/virtual_machine/whp.rs:1380

• This ordering protects the HYPERLIGHT_MAX_SURROGATES=0 path, but the existing no-surrogate test drops only an unmapped VM, while the mapped-file cleanup test runs with the default surrogate mode. Add a Windows regression test that maps a file with surrogates disabled and then drops the VM, so this lifetime requirement is exercised.

        for (handle, view) in self.file_mappings.drain(..) {
            release_file_mapping(view, handle);

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ludfjig]

Closing, this was wrong! Whoops