server/lib: add generic hypervisor enlightenment interface #846
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `cpuid` field in an instance spec's board is optional. If it is `None`, have propolis-server read bhyve's default CPUID values and insert them into the spec as though the caller had specified them. This has two benefits: 1. propolis-server can set up CPUID values in the hypervisor leaf range without requiring callers to set CPUID values in the standard and extended ranges. 2. When a VM migrates, the default CPUID settings from the source will transfer to the target, even if the target host's bhyve supplies different default CPUID values than the source host's.
gjcolombo
commented
Jan 30, 2025
hawkw
reviewed
Jan 30, 2025
pfmooney
reviewed
Jan 31, 2025
hawkw
reviewed
Jan 31, 2025
pfmooney
approved these changes
Feb 1, 2025
hawkw
approved these changes
Feb 3, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement some basic infrastructure to support hypervisor enlightenments. The general idea is as follows:
EnlightenmentandEnlightenmentDevicetraits that are implemented by components that provide a particular guest-hypervisor interface.Arc<dyn EnlightenmentDevice>to the lib'smachine::Builder. The resultingMachinecontains vCPU objects that hold a reference to the selectedEnlightenment. This allows them to forward RDMSR/WRMSR exits to the enlightenment stack for (possible) processing.Enlightenment::add_cpuidto allow hypervisor interfaces to inject CPUID identifiers into theCpuidSets that are used to configure the VM's vCPUs.EnlightenmentDeviceto anArc<dyn Lifecycle>and use that reference to dispatch lifecycle and migration notifications to the active enlightenment stack.Implement a
BhyveGuestInterfaceenlightenment stack that implements these interfaces but does nothing beyond exposing its vendor string in CPUID leaf 0x4000_0000. This matches the hypervisor-related CPUID and MSR behavior guests would have gotten before this change. More interesting hypervisor interfaces are left for future PRs.Add an instance spec field to allow propolis-server clients to select an enlightenment stack. If not specified this defaults to the bhyve interface; this provides compatibility when migrating to/from servers built without this code.
Tests: cargo test; PHD w/Alpine, Debian 11, and WS2022 guests; verified in an ad hoc VM that leaf 0x40000000 returns the correct data to a Debian guest.
Related to #328.