Re: [PATCH v4] x86/hyperv: use dynamically allocated page for hypercalls

On 16/07/2026 7:35 pm, Ariadne Conill wrote:
> Previously, the Hyper-V guest code placed the hypercall page at a
> fixed, hardcoded location: the top-most MFN of the guest physical
> address space (HV_HCALL_MFN). To make this work, an e820_fixup hook
> reserved that range as E820_RESERVED so nothing else would claim it.
>
> This assumes the top-most physical frame is actually backed by RAM (or
> at least mapped to something), which is not guaranteed. On Azure
> compute guests it is not: the top-most MFN is not physically mapped to
> anything. When we program HV_X64_MSR_HYPERCALL to point at that frame
> and subsequently execute through the hypercall page via the fixmap, the
> access faults and Xen panics during early boot.
>
> Instead of guessing at a physical address, allocate a real xenheap page
> and use its MFN for the hypercall page. This frame is always backed and
> mapped, so the fault no longer occurs. The e820_fixup hook and the
> HV_HCALL_MFN definition are no longer needed and are removed.
>
> Signed-off-by: Ariadne Conill <[email protected]>

This is certainly nicer than before.  But, it was intentional to be a
page not backed by RAM, and "out of the way".

IIRC, the Viridian hypercall page is described as an overlay which comes
into place, and shadows whatever is behind it.  It is also mapped
read-only which means it will shatter superpages (hence putting it "out
of the way"), and yield's #GP when trying to write to it (this is not so
easy to achieve, so is clearly deliberate).

From the commit message, you seem to be saying that selecting a page
which isn't actually RAM doesn't appear to work?  What fault precisely
do you get?

> ---
>  xen/arch/x86/guest/hyperv/hyperv.c      | 19 +++++++++----------
>  xen/arch/x86/include/asm/guest/hyperv.h |  3 ---
>  2 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c
> index 90757e0793..d98d02fb80 100644
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -99,10 +99,18 @@ static void __init setup_hypercall_page(void)
>      rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
>      if ( !hypercall_msr.enable )
>      {
> -        mfn = HV_HCALL_MFN;
> +        void *hcall_page = alloc_xenheap_page();

We never access the page via it's main alias.  We configure FIXMAP_X to
point at it.

So I think this is safe to be domheap page not a xenheap page.

~Andrew