Skip to content

virt_mshv_vtl, SNP: Fix a todo in the intercept processing #1628

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

romank-msft
Copy link
Contributor

Implement what the TODO requests:

  • Add a comment to explain why halt messages are expected,
  • Check that the only exception intercept messages are for the VC traps, and document that.

Tested by booting various SEV-SNP VMs.

Implement what the TODO requests:

* Add a comment to explain why halt messages are expected,
* Check that the only exception intercept messages are for the VC traps,
and document that.

Tested by booting various SEV-SNP VMs.
@romank-msft romank-msft requested a review from a team as a code owner June 30, 2025 21:39
// Ignore.
//
// TODO SNP: Figure out why we are getting these.
HvMessageType::HvMessageTypeX64Halt => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Where is it being processed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  • Above in the match block, there is an arm for the HLT exit,
  • In the same block, when processing the MSR exit, read_msr_snp is called which checks for hvdef::HV_X64_MSR_GUEST_IDLE.

The intercept message from the hypervisor can't offer a better/more trustworthy data than that one (generated by the hardware). Both cases are handled with the VP "parked" in the state allowing for interrupts being delivered. That all made the impression all that's required to be done must be already done.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we should assert or check/warn that the SevExitCode is what we'd expect here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants