RE: [PATCH] mshv: Align huge page stride with guest mapping

[Michael Kelley <mhklinux@outlook.com>]

From: Michael Kelley Sent: Monday, December 22, 2025 10:25 AM
> 
[snip]
> 
> Separately, in looking at this, I spotted another potential problem with
> 2 Meg mappings that somewhat depends on hypervisor behavior that I'm
> not clear on. To create a new region, the user space VMM issues the
> MSHV_GET_GUEST_MEMORY ioctl, specifying the userspace address, the
> size, and the guest PFN. The only requirement on these values is that the
> userspace address and size be page aligned. But suppose a 4 Meg region is
> specified where the userspace address and the guest PFN have different
> offsets modulo 2 Meg. The userspace address range gets populated first,
> and may contain a 2 Meg large page. Then when mshv_chunk_stride()
> detects a 2 Meg aligned guest PFN so HVCALL_MAP_GPA_PAGES can be told
> to create a 2 Meg mapping for the guest, the corresponding system PFN in
> the page array may not be 2 Meg aligned. What does the hypervisor do in
> this case? It can't create a 2 Meg mapping, right? So does it silently fallback
> to creating 4K mappings, or does it return an error? Returning an error would
> seem to be problematic for movable pages because the error wouldn't
> occur until the guest VM is running and takes a range fault on the region.
> Silently falling back to creating 4K mappings has performance implications,
> though I guess it would work. My question is whether the
> MSHV_GET_GUEST_MEMORY ioctl should detect this case and return an
> error immediately.
> 

In thinking about this more, I can answer my own question about the
hypervisor behavior. When HVCALL_MAP_GPA_PAGES is set, the full
list of 4K system PFNs is not provided as an input to the hypercall, so
the hypervisor cannot silently fall back to 4K mappings. Assuming
sequential PFNs would be wrong, so it must return an error if the
alignment of a system PFN isn't on a 2 Meg boundary.

For a pinned region, this error happens in mshv_region_map() as
called from  mshv_prepare_pinned_region(), so will propagate back
to the ioctl. But the error happens only if pin_user_pages_fast()
allocates one or more 2 Meg pages. So creating a pinned region
where the guest PFN and userspace address have different offsets
modulo 2 Meg might or might not succeed.

For a movable region, the error probably can't occur.
mshv_region_handle_gfn_fault() builds an aligned 2 Meg chunk
around the faulting guest PFN. mshv_region_range_fault() then
determines the corresponding userspace addr, which won't be on
a 2 Meg boundary, so the allocated memory won't contain a 2 Meg
page. With no 2 Meg pages, mshv_region_remap_pages() will
always do 4K mappings and will succeed. The downside is that a
movable region with a guest PFN and userspace address with
different offsets never gets any 2 Meg pages or mappings.

My conclusion is the same -- such misalignment should not be
allowed when creating a region that has the potential to use 2 Meg
pages. Regions less than 2 Meg in size could be excluded from such
a requirement if there is benefit in doing so. It's possible to have
regions up to (but not including) 4 Meg where the alignment prevents
having a 2 Meg page, and those could also be excluded from the
requirement.

Michael