| Message ID | 20200319055842.673513-5-arilou@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/kvm/hyper-v: add support for synthetic debugger | expand |
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index 4c482ef1eaa9..67f9893150c3 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -1645,7 +1645,10 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *current_vcpu, u64 ingpa, u64 outgpa, bool kvm_hv_hypercall_enabled(struct kvm *kvm) { - return READ_ONCE(kvm->arch.hyperv.hv_hypercall) & HV_X64_MSR_HYPERCALL_ENABLE; + struct kvm_hv *hv = &kvm->arch.hyperv; + + return READ_ONCE(hv->hv_hypercall) & HV_X64_MSR_HYPERCALL_ENABLE || + (hv->hv_syndbg.active && READ_ONCE(hv->hv_guest_os_id) != 0); } static void kvm_hv_hypercall_set_result(struct kvm_vcpu *vcpu, u64 result)
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 and the syndbg feature is enabled. Signed-off-by: Jon Doron <arilou@gmail.com> --- arch/x86/kvm/hyperv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)