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.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
