Re: [PATCH] x86/hyperv: Adjust hypercall page placement

[Ariadne Conill <ariadne@ariadne.space>]

Hi,

> On Apr 24, 2025, at 6:48 AM, Alejandro Vallejo <agarciav@xxxxxxx> wrote:
> 
> On Thu Apr 24, 2025 at 1:45 PM BST, 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 <agarciav@xxxxxxx>
> 
> After a side discussion, this seems on the unsafe side of things due to
> potential collision with MMIO. I'll resend (though not today) with the
> page overlapping a RAM page instead. Possibly the last page of actual
> RAM.

We have been working on bringing Xen up on Azure over at Edera, and have 
encountered this problem.  Our solution to this problem was to change Xen to 
handle the hypercall trampoline page in the same way as Linux: dynamically 
allocating a page from the heap and then marking it as executable.

This approach should avoid the issues with MMIO and page overlaps.  Would it be 
more interesting to start with our patch instead?

Ariadne