On 26.04.2025 01:43, 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.
>
> Changes from v1:
> - Continue to use fixmap infrastructure
> - Use panic in Hyper-V setup() function instead of returning -ENOMEM
> on hypercall page allocation failure
Nit: This part wants to go ...
> 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>
> ---
... somewhere below such a separator.
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -98,7 +98,13 @@ 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 )
Nit (style): Blank line please between declaration(s) and statement(s). (Both
can probably be taken care of upon committing if no other need for a v3 arises.)
Jan
