Re: [Xen-devel] [PATCH v2 6/8] x86/hyperv: provide percpu hypercall input page

[Wei Liu <wl@xxxxxxx>]

On Fri, Jan 03, 2020 at 04:57:11PM +0000, Andrew Cooper wrote:
> On 03/01/2020 16:55, Wei Liu wrote:
> > On Fri, Jan 03, 2020 at 04:30:49PM +0000, Andrew Cooper wrote:
> >> On 03/01/2020 16:08, Wei Liu wrote:
> >>> @@ -83,14 +84,39 @@ static void __init setup_hypercall_page(void)
> >>>      wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> >>>  }
> >>>  
> >>> +static void setup_hypercall_pcpu_arg(void)
> >>> +{
> >>> +    struct page_info *pg;
> >>> +    void *mapping;
> >>> +    unsigned int cpu = smp_processor_id();
> >>> +
> >>> +    pg = alloc_domheap_page(NULL, 0);
> >>> +    if ( !pg )
> >>> +        panic("Failed to setup hypercall input page for %u\n", cpu);
> >>> +
> >>> +    mapping = __map_domain_page_global(pg);
> >>> +    if ( !mapping )
> >>> +        panic("Failed to map hypercall input page for %u\n", cpu);
> >> Sorry I didn't spot this before, but an always-mapped domheap page is
> >> just alloc_xenheap_page() (give or take NUMA positioning above the 5T
> >> boundary, which isn't used here).
> > I had the (wrong) impression that using domheap was preferred.
> >
> > I'm fine with switching to xenheap, of course.
> 
> This is a frame which Xen needs to have a mapping to in perpetuity, to
> make hypercalls.
> 
> Most examples in code are a regular domheap frame which, after some
> guest action, requires mapping in Xen for a period of time, or frames
> which we want to have specific NUMA properties, and may be beyond the
> end of the directmap.

Alright.

If we use xenheap here I can drop the tracking structure.

I will change that in v3.

Wei.

> 
> ~Andrew

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