Re: [Xen-devel] [PATCH v4 2/7] x86/hyperv: setup hypercall page

[Wei Liu <wl@xxxxxxx>]

On Thu, Jan 23, 2020 at 12:18:41PM +0100, Jan Beulich wrote:
> On 22.01.2020 21:23, Wei Liu wrote:
> > --- a/xen/arch/x86/e820.c
> > +++ b/xen/arch/x86/e820.c
> > @@ -36,6 +36,22 @@ boolean_param("e820-verbose", e820_verbose);
> >  struct e820map e820;
> >  struct e820map __initdata e820_raw;
> >  
> > +static unsigned int find_phys_addr_bits(void)
> > +{
> > +    uint32_t eax;
> > +    unsigned int phys_bits = 36;
> > +
> > +    eax = cpuid_eax(0x80000000);
> > +    if ( (eax >> 16) == 0x8000 && eax >= 0x80000008 )
> > +    {
> > +        phys_bits = (uint8_t)cpuid_eax(0x80000008);
> > +        if ( phys_bits > PADDR_BITS )
> > +            phys_bits = PADDR_BITS;
> > +    }
> > +
> > +    return phys_bits;
> > +}
> 
> Instead of this, how about pulling further ahead the call to
> early_cpu_init() in setup.c? (Otherwise the function wants to
> be __init at least.)

I can certainly try that, but that would require modifying e820.c
nonetheless because we can drop the cpuid invocation here if the move is
successful.

> 
> > @@ -357,6 +373,21 @@ static unsigned long __init find_max_pfn(void)
> >              max_pfn = end;
> >      }
> >  
> > +#ifdef CONFIG_HYPERV_GUEST
> > +    {
> > +   /*
> > +    * We reserve the top-most page for hypercall page. Adjust
> > +    * max_pfn if necessary.
> > +    */
> > +        unsigned int phys_bits = find_phys_addr_bits();
> > +        unsigned long hcall_pfn =
> > +          ((1ull << phys_bits) - 1) >> PAGE_SHIFT;
> > +
> > +        if ( max_pfn >= hcall_pfn )
> > +          max_pfn = hcall_pfn - 1;
> > +    }
> > +#endif
> 
> This wants abstracting away: There shouldn't be Hyper-V specific
> code in here if at all possible, and the adjustment also shouldn't
> be made unless actually running on Hyper-V.
> 

I will introduce a hook called hypervisor_reserve_top_pages.

> > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > @@ -18,17 +18,27 @@
[...]
> > @@ -72,6 +82,43 @@ const struct hypervisor_ops *__init hyperv_probe(void)
> >      return &ops;
> >  }
> >  
> > +static void __init setup_hypercall_page(void)
> > +{
> > +    union hv_x64_msr_hypercall_contents hypercall_msr;
> > +    union hv_guest_os_id guest_id;
> > +    unsigned long mfn;
> > +
> > +    rdmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw);
> > +    if ( !guest_id.raw )
> > +    {
> > +        guest_id.raw = generate_guest_id();
> > +        wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw);
> > +    }
> > +
> > +    rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> > +    if ( !hypercall_msr.enable )
> > +    {
> > +        mfn = ((1ull << paddr_bits) - 1) >> HV_HYP_PAGE_SHIFT;
> 
> Along the lines of the abstracting-away request above: How is
> anyone to notice what else needs changing if it is decided
> that this page gets moved elsewhere?

I don't have a good answer to this other than documenting. It is
probably as fragile as livepatch or pcpu stub.

> 
> > +        hypercall_msr.enable = 1;
> > +        hypercall_msr.guest_physical_address = mfn;
> > +        wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> 
> So on Hyper-V the hypervisor magically populates this page as
> a side effect of the MSR write?

Yes. See Michael's reply.

Wei.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel