-
Notifications
You must be signed in to change notification settings - Fork 22
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
lib: add better management of Hyper-V overlay pages #851
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new changes look good to me! Perhaps worth getting a second opinion?
I found a bug during ad hoc testing: I'm going to merge #849 and rebase this branch before pushing a fix and working on other PR feedback. |
07e3c11
to
161729b
Compare
a3186ef should fix this. |
Add to the Hyper-V module some supporting types to support overlay pages. A Hyper-V overlay page is a sort of auxiliary page of guest memory that "covers up" or temporarily "replaces" a specific physical page in the guest's physical memory, such that accesses to the overlaid GPA end up accessing the overlay instead. See the doc comments throughout
overlay.rs
for many more details.To avoid creating a 2,500-line patch, this PR omits direct migration of overlay manager state. Instead, the target Hyper-V stack re-creates all overlays during import based on the contents of its imported MSRs. This is somewhat dangerous: a single guest page is allowed to have multiple overlays, and there's nothing in this change that guarantees that the source and target will agree on which overlay is active at migration time. The danger is mitigated here by having only one overlay page in the whole VM (the hypercall page), but this will need to be addressed in a follow-up PR before adding any more overlay kinds (like a reference TSC page).
Tests: cargo tests, including new unit tests of the overlay manager; PHD runs with Alpine and Debian 11 guests; manually migrated a VM and made sure the hypercall page was preserved properly over migration.
Related to #850 (but doesn't close it since migration work is still pending).