summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/net/forwarding/router_multicast.sh
diff options
context:
space:
mode:
authorJon Doron <arilou@gmail.com>2020-05-29 16:45:41 +0300
committerPaolo Bonzini <pbonzini@redhat.com>2020-06-01 04:26:11 -0400
commit45c38973ed1868b8448079edd48bf24ab8b326fa (patch)
treee080322f6dbae4ee754b763a4b505b2c14fa37c5 /tools/testing/selftests/net/forwarding/router_multicast.sh
parentf97f5a56f5977311f3833056a73cdbb0ee56cb1e (diff)
x86/kvm/hyper-v: enable hypercalls regardless of hypercall page
Microsoft's kdvm.dll dbgtransport module does not respect the hypercall page and simply identifies the CPU being used (AMD/Intel) and according to it simply makes hypercalls with the relevant instruction (vmmcall/vmcall respectively). The relevant function in kdvm is KdHvConnectHypervisor which first checks if the hypercall page has been enabled via HV_X64_MSR_HYPERCALL_ENABLE, and in case it was not it simply sets the HV_X64_MSR_GUEST_OS_ID to 0x1000101010001 which means: build_number = 0x0001 service_version = 0x01 minor_version = 0x01 major_version = 0x01 os_id = 0x00 (Undefined) vendor_id = 1 (Microsoft) os_type = 0 (A value of 0 indicates a proprietary, closed source OS) and starts issuing the hypercall without setting the hypercall page. To resolve this issue simply enable hypercalls also if the guest_os_id is not 0. Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Jon Doron <arilou@gmail.com> Message-Id: <20200529134543.1127440-5-arilou@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/testing/selftests/net/forwarding/router_multicast.sh')
0 files changed, 0 insertions, 0 deletions