On Mon Apr 28, 2025 at 8:57 PM BST, Ariadne Conill wrote:
> Previously Xen placed the hypercall page at the highest possible MFN,
> but this caused problems on systems where there is more than 36 bits
> of physical address space.
>
> In general, it also seems unreliable to assume that the highest possible
> MFN is not already reserved for some other purpose.
>
> Fixes: 620fc734f854 ("x86/hyperv: setup hypercall page")
> Cc: Alejandro Vallejo <agarc...@amd.com>
> Cc: Alexander M. Merritt <alexan...@edera.dev>
> Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
Reviewed-by: Alejandro Vallejo <agarc...@amd.com>
I'm happy with the patch as-is, and I'm equally happy...
> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
> b/xen/arch/x86/guest/hyperv/hyperv.c
> index 6989af38f1..f69f596441 100644
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -98,10 +98,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();
> +
> + if ( !hcall_page )
> + panic("Hyper-V: Failed to allocate hypercall trampoline page\n");
... with Roger's suggestion to probe <4G first with MEMF(32) here.
> +
> + mfn = virt_to_mfn(hcall_page);
> hypercall_msr.enable = 1;
> hypercall_msr.guest_physical_address = mfn;
> wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> +
> + dprintk(XENLOG_INFO,
> + "Hyper-V: Allocated hypercall page at MFN %lx\n", mfn);
nit: This is a personal preference thing, but I find %lx is very
unhelpful when the variable is something like 0x123, as 123 might be
misinterpreted to be in decimal. An mfn is not nearly as problematic as
an error code, but %#lx avoids the ambiguity altogether.
Cheers,
Alejandro
