fix CVM boot failure on MSHV - #7548
Conversation
5d38232 to
ebed942
Compare
ebed942 to
649e47e
Compare
|
@likebreath @liuw Would you be able to take a look here? |
Exactly, this function is very ugly. I think after this PR merged we can simplify and make it more readable. Thx |
d7cd3ed to
9b88872
Compare
|
There is a shell check error in the main branch. |
Right, that is my main concern too, but I haven't had a chance to dig deeper and come up with a proposal. @russell-islam While you are working on this, could you summarize the VM boot requirements for the various permutations and add that to the issue? Specifically, we need to understand the matrix across hypervisors (KVM/MSHV), architectures (x86_64/AArch64), and VM types (legacy vs. confidential). |
likebreath
left a comment
There was a problem hiding this comment.
LGTM for legacy VM use cases, specifically KVM (x86_64/AArch64).
However, we still need a review of the impact on confidential VMs, especially regarding MSHV. I also have a question regarding this below.
9b88872 to
a5e8dd0
Compare
I am working on that. |
Recent changes related to arm64 support in MSHV exposed inconsistencies in the VM initialization and CVM boot paths. The VM creation flow currently diverges across multiple scenarios, including regular MSHV, CVM, and arm64, with each path performing guest initialization steps in a different order. Certain platform-specific requirements further constrain the ordering of operations, such as the timing of address space creation, IGVM loading, interrupt controller setup, and payload loading. For CVM case address-space creation must be done after IGVM loading, and PSP measurement. For Regular and arm64 this memory initialization must be done early. For MSHV, vm.init() and sev_snp.init() are called in different order which is run time and build time conditionally checked. Additionally, while the KVM initialization path differs slightly from MSHV, it shares common logic that is currently split across separate conditional and build-time code paths, contributing to fragmentation of the overall flow. This change restructures the VM creation and initialization sequence to better align shared logic, enforce scenario-specific ordering constraints, and ensure consistent and correct behavior across all supported configurations. In doing so, it restores proper CVM boot behavior and improves the maintainability of the initialization code. Signed-off-by: Muminul Islam <[email protected]>
a5e8dd0 to
646e43c
Compare
|
What's the status of this PR - are we ready to move forward? |
It needs a review from MSHV side. |
|
@liuw @NunoDasNeves @anirudhrb Could you please take a look? |
anirudhrb
left a comment
There was a problem hiding this comment.
Tested guest boot on arm64 MSHV.
| } | ||
| } | ||
| #[cfg(feature = "sev_snp")] | ||
| if sev_snp_enabled { |
There was a problem hiding this comment.
All this ugly "double checking" for sev_snp support could be fixed if the config option is always available, but just hardcoded to false when support is not compiled in... I guess that's out of scope here.
You could probably clean up this function, however, by doing the following (above, where sev_snp_enabled is defined):
let sev_snp_enabled = cfg_if::cfg_if! {
if #[cfg(feature = "sev_snp")] {
config.lock().unwrap().is_sev_snp_enabled()
} else {
false
}
}I haven't checked this but I think it's worth doing in this PR if at all possible.
There was a problem hiding this comment.
Let's land this one as it is, since we all agree on its functional changes. Please send out a PR to improve the code quality. Thank you.
| vm.sev_snp_init().map_err(Error::InitializeSevSnpVm)?; | ||
| } | ||
|
|
||
| #[cfg(feature = "sev_snp")] |
There was a problem hiding this comment.
see above, can we remove this check if sev_snp_enabled is always defined?
| .unwrap() | ||
| .allocate_address_space() | ||
| .map_err(Error::MemoryManager)?; | ||
| cfg_if::cfg_if! { |
There was a problem hiding this comment.
See above, can we reduce this to a single check if sev_snp_enabled is always defined?
| }; | ||
| // First case is when sev_snp is enabled(compiled), but run time non-cvn | ||
| // guest boot. 2nd case is when sev_snp is not compiled in, KVM and MSHV regular guest boot. | ||
| cfg_if::cfg_if! { |
There was a problem hiding this comment.
See above, can we reduce this to a single check if sev_snp_enabled is always defined?
| .map_err(Error::CpuManager)?; | ||
| // First case is when sev_snp is enabled(compiled), but run time non-cvn | ||
| // guest boot. 2nd case is when sev_snp is not compiled in, KVM and MSHV regular guest boot. | ||
| cfg_if::cfg_if! { |
There was a problem hiding this comment.
See above, can we reduce this to a single check if sev_snp_enabled is always defined?
c9cd82b
Recent changes related to arm64 support in MSHV exposed inconsistencies in the VM initialization and CVM boot paths.
The VM creation flow currently diverges across multiple scenarios, including regular MSHV, CVM, and arm64, with each path performing guest initialization steps in a different order. Certain platform-specific requirements further constrain the ordering
of operations, such as the timing of address space creation, IGVM loading, interrupt controller setup, and payload loading. For
CVM case address-space creation must be done after IGVM loading, and PSP measurement. For Regular and arm64 this memory initialization must be done early. For MSHV, vm.init() and sev_snp.init() are called in different order which is run time and build time conditionally checked.
Additionally, while the KVM initialization path differs slightly from MSHV, it shares common logic that is currently split across
separate conditional and build-time code paths, contributing to fragmentation of the overall flow.
This change restructures the VM creation and initialization sequence to better align shared logic, enforce scenario-specific ordering constraints, and ensure consistent and correct behavior across all supported configurations. In doing so, it restores proper CVM boot behavior and improves the maintainability of the initialization code.