|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4/8] x86/hyperv: setup hypercall page
On Sun, Dec 29, 2019 at 07:54:30PM +0000, Michael Kelley wrote:
[...]
> >
> > +static void __init setup_hypercall_page(void)
> > +{
> > + union hv_x64_msr_hypercall_contents hypercall_msr;
> > +
> > + /* Unfortunately there isn't a really good way to unwind Xen to
> > + * not use Hyper-V hooks, so panic if anything goes wrong.
> > + *
> > + * In practice if page allocation fails this early on it is
> > + * unlikely we can get a working system later.
> > + */
> > + hv_hypercall_page = alloc_domheap_page(NULL, 0);
> > + if ( !hv_hypercall_page )
> > + panic("Failed to allocate Hyper-V hypercall page\n");
> > +
> > + hv_hypercall = __map_domain_page_global(hv_hypercall_page);
> > + if ( !hv_hypercall )
> > + panic("Failed to map Hyper-V hypercall page\n");
> > +
> > + rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> > + hypercall_msr.enable = 1;
> > + hypercall_msr.guest_physical_address =
> > page_to_maddr(hv_hypercall_page);
>
> The "guest_physical_address" field is actually the guest physical page number.
> So the physical address needs to be right shifted 12 bits before being stored
> here. I'd recommend using HV_HYP_PAGE_SHIFT from hyperv-tlfs.h as
> the shift value; it was introduced to deal with the possibility that the page
> size used and expected by the Hyper-V interface is different from the page
> size used by the guest VM (which can happen on ARM64, though not on x86).
Good catch, and thanks for the tip here.
I will fix this in the next version.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |