Skip to content

Conversation

@ludfjig
Copy link
Contributor

@ludfjig ludfjig commented Dec 10, 2025

Some follow up items from #924. Please review commit by commit

  • Moves kvm.rs/hyperv_linux.rs/hyperv_windows.rs into new vm module.
  • Renames Hyperv_linux.rs to mshv.rs. Renames hyperv_windows.rs to whp.rs
  • Renames Hypervisor trait to Vm trait
  • Renames HyperlightExit to VmExit
  • Moves some hypervisor specific code out from sandbox module, to hypervisor/vm module

Note that this PR does not modify any code (with exception of renames and moves)

Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>

Clean up import paths after file move

Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>

Rename hyperv_linux to mshv, hyperv_windows to whp

Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
@ludfjig ludfjig added the kind/refactor For PRs that restructure or remove code without adding new functionality. label Dec 10, 2025
@ludfjig ludfjig marked this pull request as ready for review December 11, 2025 00:05
@ludfjig ludfjig requested a review from Copilot December 11, 2025 00:05
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR performs a significant refactoring of VM-related code to improve organization and naming consistency. It moves hypervisor-specific implementation files from the root hypervisor module and the sandbox module into a new hypervisor/vm submodule, renames files to use shorter and more descriptive names (mshv, whp), and renames core abstractions (Hypervisor trait → Vm trait, HyperlightExitVmExit) to better reflect their purpose.

Key Changes:

  • Created new hypervisor/vm module to consolidate VM implementations (KVM, MSHV, WHP)
  • Renamed Hypervisor trait to Vm and HyperlightExit enum to VmExit for clearer semantics
  • Moved hypervisor detection logic from sandbox::hypervisor to hypervisor::vm

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
src/hyperlight_host/src/sandbox/mod.rs Removed hypervisor submodule and moved is_hypervisor_present() to hypervisor/vm module
src/hyperlight_host/src/sandbox/hypervisor.rs Deleted - functionality moved to hypervisor/vm/mod.rs
src/hyperlight_host/src/lib.rs Updated public export to reference hypervisor::vm::is_hypervisor_present
src/hyperlight_host/src/hypervisor/vm/mod.rs New module containing VM trait, VmExit enum, hypervisor detection, and test moved from sandbox
src/hyperlight_host/src/hypervisor/vm/whp.rs Renamed from hyperv_windows.rs; updated trait implementation and imports
src/hyperlight_host/src/hypervisor/vm/mshv.rs Renamed from hyperv_linux.rs; updated trait implementation and imports
src/hyperlight_host/src/hypervisor/vm/kvm.rs Moved to vm submodule; updated trait implementation and imports
src/hyperlight_host/src/hypervisor/mod.rs Removed Hypervisor trait, HyperlightExit enum, and old module declarations
src/hyperlight_host/src/hypervisor/hyperlight_vm.rs Updated imports to reference vm module and new Vm/VmExit names; updated comments
src/hyperlight_host/src/hypervisor/gdb/mod.rs Updated DebuggableVm trait to extend Vm instead of Hypervisor

Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
Copy link
Contributor

@danbugs danbugs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the change from HypervisorVm. I agree that it is more accurate. Same for VmExit over HyperlightExit.

Though, iirc, in the past, when we considered changing from hyperv_* to mshv/whp, we opted to keep the previous names.

@ludfjig
Copy link
Contributor Author

ludfjig commented Dec 11, 2025

I like the change from HypervisorVm. I agree that it is more accurate. Same for VmExit over HyperlightExit.

Though, iirc, in the past, when we considered changing from hyperv_* to mshv/whp, we opted to keep the previous names.

THanks. I think the renaming was discarded in the past due to making a PR too hard to review

@danbugs
Copy link
Contributor

danbugs commented Dec 11, 2025

I like the change from HypervisorVm. I agree that it is more accurate. Same for VmExit over HyperlightExit.
Though, iirc, in the past, when we considered changing from hyperv_* to mshv/whp, we opted to keep the previous names.

THanks. I think the renaming was discarded in the past due to making a PR too hard to review

I think Simon also mentioned the hyperv_* names are more descriptive: #517 (comment)

@jsturtevant
Copy link
Contributor

LGTM, I tend to agree that I perfer hyperv_linux and hyperv_windows over mshv and whp.

@ludfjig
Copy link
Contributor Author

ludfjig commented Dec 11, 2025

I like whp (windows hypervisor platform) because it's the name of the API we use https://learn.microsoft.com/en-us/virtualization/api/hypervisor-platform/hypervisor-platform

Copy link
Contributor

@simongdavies simongdavies left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just al little concerned about VM name since we also will have VM as an abbreviation for Virtual Memory

#[cfg(kvm)]
/// Functionality to manipulate KVM-based virtual machines
pub(crate) mod kvm;
pub(crate) mod vm;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we call this virtual_machine, #1093 introduces a vm module too (we should probably rename that to virtual_memory a well

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gosh I just reviewed that and didn't notice that was vm as in virtual_memory. Should #1093 also rename vm->virtual_memory?

/// Trait for VMs that support debugging capabilities.
/// This extends the base Hypervisor trait with GDB-specific functionality.
pub(crate) trait DebuggableVm: Hypervisor {
pub(crate) trait DebuggableVm: Vm {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again can we consider calling this VirtualMachine and DebuggableVirtualMachine? I agree with the rename its just the ambiguity with vm as an abbreviation for VirtualMemory

}
} else if #[cfg(target_os = "windows")] {
if whp::is_hypervisor_present() {
Some(HypervisorType::Whp)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realised that we have code in unitializedsandbox::new that checks for supported versions of windows , I don't know why that code is there and not wrapped up in the check for whp presence here , IIRC that code is to check that we are running on Windows 11 or Windows 2022 or later because we need an API that is only available on those Os versions

@simongdavies
Copy link
Contributor

I like the change from HypervisorVm. I agree that it is more accurate. Same for VmExit over HyperlightExit.
Though, iirc, in the past, when we considered changing from hyperv_* to mshv/whp, we opted to keep the previous names.

THanks. I think the renaming was discarded in the past due to making a PR too hard to review

I think Simon also mentioned the hyperv_* names are more descriptive: #517 (comment)

Well I must be mellowing rapidly since I don't really mind that renaming, I'm easy either way (although being totally contradictory to my previous comments the new names do have a certain amount of symmetry to them). Not sure about VM abbreviation though and don't like ::vm::vm much either

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/refactor For PRs that restructure or remove code without adding new functionality.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants