openhcl_boot: derive the hw id chunk size from the page size - #4144
Merged
Steven Malis (smalis-msft) merged 1 commit intoAug 4, 2026
Merged
Conversation
get_vp_index_from_hw_id chunked hardware IDs at a hardcoded 512 per call. The input page holds a 16-byte header, leaving 4080 bytes, so on aarch64 (HwId is u64) a 512-element chunk needs 4096 bytes and write_to_prefix fails, panicking on the unwrap. This starts at 511 CPUs, not 512 as the issue estimates, because the header was not counted. Compute the limit from the page size, header and HwId size the way the other rep hypercalls in this file already do: 510 on aarch64, 1020 on x86_64. Both fit the output page and the 12-bit rep count field.
|
This PR modifies files containing For more on why we check whole files, instead of just diffs, check out the Rustonomicon |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a panic in openhcl_boot’s HvCall::get_vp_index_from_hw_id by deriving the maximum per-hypercall chunk size from the actual input page capacity (page size minus hypercall header) and the HwId element size, instead of using a hardcoded 512.
Changes:
- Compute
MAX_PER_CALLfromHV_PAGE_SIZE, theGetVpIndexFromApicIdheader size, andsize_of::<HwId>()to preventwrite_to_prefixfailures (notably on aarch64). - Use the same
HEADER_SIZEconstant for both the chunk-size calculation and the buffer offset used to write thehw_ids, avoiding future drift.
Steven Malis (smalis-msft)
approved these changes
Aug 1, 2026
Steven Malis (smalis-msft)
enabled auto-merge (squash)
August 4, 2026 15:39
Steven Malis (smalis-msft)
merged commit Aug 4, 2026
34d639b
into
microsoft:main
99 of 101 checks passed
This file contains hidden or 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
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.
get_vp_index_from_hw_idchunks hardware IDs at a hardcoded 512 per call, but the input page carries a 16-byteGetVpIndexFromApicIdheader, leaving 4080 bytes. On aarch64HwIdis au64, so a 512-element chunk needs 4096 bytes,write_to_prefixreturnsErrand theunwrappanics. Thetodoabove that line tracked this against this issueone correction to the issue text: the panic starts at 511 CPUs, not 512. The estimate of
8 * 512 == 4096did not count the header, so the last chunk that still fits is 510this computes the limit from the page size, the header and
size_of::<HwId>()the wayaccept_vtl2_pagesandapply_vtl2_protectionsin the same file already do, giving 510 on aarch64 and 1020 on x86_64. Both fit the output page (n * 4bytes) and the 12-bit rep count field. The offset now uses the sameHEADER_SIZEconstant as the chunk limit, matchingset_registerandget_register, so the two can no longer drift apartverified the constants by compiling
openhcl_bootfor both targets with a temporary const assertion, and checked the arithmetic against zerocopy directly: 510u64s fit the 4080-byte tail, 511 do notFixes #745