On 24.04.2025 14:45, Alejandro Vallejo wrote:
> Xen nowadays crashes under some Hyper-V configurations when
> paddr_bits>36. At the 44bit boundary we reach an edge case in which the
> end of the guest physical address space is not representable using 32bit
> MFNs. Furthermore, it's an act of faith that the tail of the physical
> address space has no reserved regions already.
>
> This commit uses the first unused MFN rather than the last, thus
> ensuring the hypercall page placement is more resilient against such
> corner cases.
>
> While at this, add an extra BUG_ON() to explicitly test for the
> hypercall page being correctly set, and mark hcall_page_ready as
> __ro_after_init.
>
> Fixes: 620fc734f854("x86/hyperv: setup hypercall page")
> Signed-off-by: Alejandro Vallejo <agarc...@amd.com>
Just in case you re-submit (as per later discussion), and respective code
was to stay, two style nits:
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -582,6 +582,20 @@ int __init e820_add_range(uint64_t s, uint64_t e,
> uint32_t type)
> return 1;
> }
>
> +uint64_t __init e820_reserve_hole(void)
> +{
> + for ( unsigned int i = 0; i < e820.nr_map; i++ )
> + {
> + uint64_t hole = e820.map[i].addr + e820.map[i].size;
> + if ( e820_add_range(hole, hole + PAGE_SIZE, E820_RESERVED) )
Blank line between declaration(s) and statement8s) please.
> + return hole;
> + }
> +
> + print_e820_memory_map(e820.map, e820.nr_map);
> + panic("Unable to find a hole in e820");
> +}
> +
> +
No double blank lines please.
Jan
