On 30/12/2019 13:33, Wei Liu wrote:
> On Mon, Dec 30, 2019 at 12:55:22PM +0000, Andrew Cooper wrote:
>> On 29/12/2019 18:33, Wei Liu wrote:
>>> @@ -71,6 +72,40 @@ 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;
>>> +
>>> + /* 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");
>> I really hope this doesn't actually function correctly. This should
>> result in an NX mapping.
>>
> Ah, stupid me. I had actually looked at Xen's implementation and thought
> "wouldn't it be nice to save one page in the image".
Its 4k, and there is a lot to be said for not having random tiny
critical bits of infrastructure spread dynamically around GFN space.
> I clearly missed that __map_domain_page_global makes the page NX.
It is hidden in the depths of PAGE_HYPERVISOR.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
