Re: [PATCH v2] x86/hyperv: use dynamically allocated page for hypercalls

[Alejandro Vallejo <agarciav@amd.com>]

On Mon Apr 28, 2025 at 10:41 AM BST, Roger Pau Monné wrote:
> On Fri, Apr 25, 2025 at 04:43:31PM -0700, 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
>> 
>> Fixes: 620fc734f854 ("x86/hyperv: setup hypercall page")
>> Cc: Alejandro Vallejo <agarciav@amd.com>
>> Cc: Alexander M. Merritt <alexander@edera.dev>
>> Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
>> ---
>>  xen/arch/x86/guest/hyperv/hyperv.c      | 17 +++++++----------
>>  xen/arch/x86/include/asm/guest/hyperv.h |  3 ---
>>  2 files changed, 7 insertions(+), 13 deletions(-)
>> 
>> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c
>> index 6989af38f1..0305374a06 100644
>> --- 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 )
>> +            panic("Hyper-V: Failed to allocate hypercall trampoline page");
>> +
>> +        printk("Hyper-V: Allocated hypercall page @ %p.\n", hcall_page);
>
> This likely wants to be a dprintk, and possibly also print the
> physical address of the used page?  And no period at the end of the
> sentence IMO.
>
> I think Xen might have used the last page in the physical address
> range to prevent HyperV from possibly shattering a superpage in the
> second stage translation page-tables if normal RAM was used?
>
> However I don't know whether HyperV will shatter super-pages if a
> sub-page of it is used to contain the hypercall page (I don't think it
> should?)

I think it's quite unlikely. Seeing how Linux simply vmalloc()s and
Microsoft seems to genuinely care about Linux in this day and age. It
seems fair to assume Hyper-V might just copy the old memory out and
rewrite it with the trampoline contents when enabling the MSR, thereby
keeping superpages together in their p2m.

>
> Thanks, Roger.

Cheers,
Alejandro