[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3] x86/hyperv: use dynamically allocated page for hypercalls
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 <agarciav@xxxxxxx> > Cc: Alexander M. Merritt <alexander@xxxxxxxxx> > Signed-off-by: Ariadne Conill <ariadne@ariadne.space> Reviewed-by: Alejandro Vallejo <agarciav@xxxxxxx> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |