Repository navigation
Hoist the XCOMP_BV read into MSHV vCPU creation - #1912
Conversation
There was a problem hiding this comment.
🟢 Approval recommended
The focused optimization preserves XSAVE reset behavior while removing the repeated hypercall.
0 open findings
What changed in this PR
Caches MSHV’s partition-fixed XSAVE format during vCPU creation, avoiding a hypercall on every reset.
Changes:
- Store XCOMP_BV once and reuse it during XSAVE reset.
- Restrict
XSAVE_MIN_SIZEto WHP. - Document the restore performance improvement.
| File | Description |
|---|---|
src/hyperlight_host/src/hypervisor/virtual_machine/mshv/x86_64.rs |
Caches and reuses XCOMP_BV. |
src/hyperlight_host/src/hypervisor/virtual_machine/mod.rs |
Narrows the XSAVE minimum-size constant to WHP. |
CHANGELOG.md |
Records the MSHV optimization. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
vCPU reset writes a zeroed XSAVE area that carries the partition's XCOMP_BV. The hypervisor derives XCOMP_BV from the partition's XSAVE features, which are fixed when the partition is created. MshvVm::new reads it once, and every reset reuses it. This removes one get_xsave hypercall from every restore. On mshv3 (AMD EPYC 7763, Linux 6.6 MSHV), snapshots/restore/default drops from 88 us to 66 us (-25%). Sandbox creation pays the read once, about +3% for create_initialized/default. Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
8b9317c to
fc81cac
Compare
Benchmark ResultsMeasured commit: kvm / amd (Linux) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
kvm / intel (Linux) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
mshv3 / amd (Linux) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
mshv3 / intel (Linux) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
hyperv-ws2025 / amd (Windows) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
hyperv-ws2025 / intel (Windows) (➖ stable)No benchmark improved or regressed. Benchmark Resultsfunction_call_codec
payload_allocation
sandboxes
slot_pool
snapshot_files
virtq_readonly
virtq_readwrite
Reported by |
Currently, every MSHV vCPU reset calls
get_xsaveto copy XCOMP_BV into the zeroed XSAVE area. This PR hoists that read into vCPU creation, and every reset reuses the value. This saves one hypercall perSandbox::restore().This is safe because XCOMP_BV depends only on the partition's XSAVE features, which are fixed at partition initialization and unaffected by guest state or snapshots.
Benchmarks
mshv3: AMD EPYC 7763, Linux 6.6 MSHV.snapshots/restore/defaultsnapshots/restore/smallsnapshots/restore/mediumguest_calls/call_with_restore/defaultguest_calls/call_with_restore/mediumsandboxes/create_initialized/defaultsandboxes/sandbox_from_snapshot/defaultEach restore saves one
get_xsavehypercall, about 22 µs. Each vCPU creation makes that hypercall once.