Use VTL-aware direct hypercall to get/set registers when possible #407
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
…crosoft#125) Modify ProcessorRunner::get_reg and ProcessorRunner::set_reg to use a direct hypercall when possible, instead of our dedicated get/set-register ioctl. Certain registers have special handling in the kernel ioctl handler. Those are left as-is. Get/set for other registers is now made with a direct hypercall. This has the benefit of being VTL-aware, so this change also adds a VTL parameter. This change also removes some proliferation of (g|s)et_vp_registers?(_inner)?, hopefully making it simpler and cleaner. The singular (g|s)et_vp_register is left as an ergonomic convenience. One unaddressed capability is making ioctls/hypercalls on a batch of registers. This is not strictly a regression, because MSHV_VP_MAX_REGISTERS was previously 1.
…oft#360) microsoft#125 introduced using a generic, VTL-aware hypercall to get and set VTL-private registers. Unfortunately, it introduced multiple sources of truth about how certain registers (in particular, Xfem) should be handled. This change modifies ProcessorRunner::set_reg and get_reg to route any VTL-shared register through the special kernel ioctl, and use the generic hypercall only for registers that are definitely VTL-private. This ensures that the decision made by get_reg and set_reg matches the assert in, e.g., get_vp_register_for_vtl.
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.
Cherry-pick PRs 125 and 360 to release/2411.
Modify ProcessorRunner::get_reg and ProcessorRunner::set_reg to use a
direct hypercall when possible, instead of our dedicated
get/set-register ioctl. Certain registers have special handling in the
kernel ioctl handler. Those are left as-is. Get/set for other registers
is now made with a direct hypercall.
This has the benefit of being VTL-aware, so this change also adds a VTL
parameter.
This change also removes some proliferation of
(g|s)et_vp_registers?(_inner)?, hopefully making it simpler and cleaner.
The singular (g|s)et_vp_register is left as an ergonomic convenience.
One unaddressed capability is making ioctls/hypercalls on a batch of
registers. This is not strictly a regression, because
MSHV_VP_MAX_REGISTERS was previously 1.
This change modifies ProcessorRunner::set_reg and get_reg to
route any VTL-shared register through the special kernel ioctl, and use
the generic hypercall only for registers that are definitely
VTL-private. This ensures that the decision made by get_reg and set_reg
matches the assert in, e.g., get_vp_register_for_vtl.