* [PATCH v4 0/5] x86/kvm/hyper-v: add support for synthetic debugger @ 2020-03-09 18:20 Jon Doron 2020-03-09 18:20 ` [PATCH v4 1/5] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit Jon Doron ` (4 more replies) 0 siblings, 5 replies; 18+ messages in thread From: Jon Doron @ 2020-03-09 18:20 UTC (permalink / raw) To: kvm, linux-hyperv; +Cc: vkuznets, Jon Doron Add support for the synthetic debugger interface of hyper-v, the synthetic debugger has 2 modes. 1. Use a set of MSRs to send/recv information 2. Use hypercalls The first mode is based the following MSRs: 1. Control/Status MSRs which either asks for a send/recv . 2. Send/Recv MSRs each holds GPA where the send/recv buffers are. 3. Pending MSR, holds a GPA to a PAGE that simply has a boolean that indicates if there is data pending to issue a recv VMEXIT. In the first patch the first mode is being implemented in the sense that it simply exits to user-space when a control MSR is being written and when the pending MSR is being set, then it's up-to userspace to implement the rest of the logic of sending/recving. In the second mode instead of using MSRs KNet will simply issue Hypercalls with the information to send/recv, in this mode the data being transferred is UDP encapsulated, unlike in the previous mode in which you get just the data to send. The new hypercalls will exit to userspace which will be incharge of re-encapsulating if needed the UDP packets to be sent. There is an issue though in which KDNet does not respect the hypercall page and simply issues vmcall/vmmcall instructions depending on the cpu type expecting them to be handled as it a real hypercall was issued. Jon Doron (5): x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit x86/hyper-v: Add synthetic debugger definitions x86/kvm/hyper-v: Add support for synthetic debugger capability x86/kvm/hyper-v: enable hypercalls regardless of hypercall page x86/kvm/hyper-v: Add support for synthetic debugger via hypercalls arch/x86/include/asm/hyperv-tlfs.h | 26 +++++ arch/x86/include/asm/kvm_host.h | 13 +++ arch/x86/kvm/hyperv.c | 162 ++++++++++++++++++++++++++++- arch/x86/kvm/hyperv.h | 5 + arch/x86/kvm/trace.h | 51 +++++++++ arch/x86/kvm/x86.c | 9 ++ include/uapi/linux/kvm.h | 11 ++ 7 files changed, 275 insertions(+), 2 deletions(-) -- 2.24.1 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v4 1/5] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit 2020-03-09 18:20 [PATCH v4 0/5] x86/kvm/hyper-v: add support for synthetic debugger Jon Doron @ 2020-03-09 18:20 ` Jon Doron 2020-03-10 16:55 ` Vitaly Kuznetsov 2020-03-09 18:20 ` [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions Jon Doron ` (3 subsequent siblings) 4 siblings, 1 reply; 18+ messages in thread From: Jon Doron @ 2020-03-09 18:20 UTC (permalink / raw) To: kvm, linux-hyperv; +Cc: vkuznets, Jon Doron Signed-off-by: Jon Doron <arilou@gmail.com> --- include/uapi/linux/kvm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 4b95f9a31a2f..7acfd6a2569a 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -189,6 +189,7 @@ struct kvm_hyperv_exit { #define KVM_EXIT_HYPERV_SYNIC 1 #define KVM_EXIT_HYPERV_HCALL 2 __u32 type; + __u32 pad; union { struct { __u32 msr; -- 2.24.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH v4 1/5] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit 2020-03-09 18:20 ` [PATCH v4 1/5] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit Jon Doron @ 2020-03-10 16:55 ` Vitaly Kuznetsov 2020-03-10 17:14 ` Jon Doron 0 siblings, 1 reply; 18+ messages in thread From: Vitaly Kuznetsov @ 2020-03-10 16:55 UTC (permalink / raw) To: Jon Doron; +Cc: kvm, linux-hyperv Jon Doron <arilou@gmail.com> writes: > Signed-off-by: Jon Doron <arilou@gmail.com> > --- > include/uapi/linux/kvm.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 4b95f9a31a2f..7acfd6a2569a 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -189,6 +189,7 @@ struct kvm_hyperv_exit { > #define KVM_EXIT_HYPERV_SYNIC 1 > #define KVM_EXIT_HYPERV_HCALL 2 > __u32 type; > + __u32 pad; > union { > struct { > __u32 msr; Sorry if I missed something but I think the suggestion was to pad this 'msr' too (in case we're aiming at making padding explicit for the whole structure). Or is there any reason to not do that? Also, I just noticed that we have a copy of this definition in Documentation/virt/kvm/api.rst - it will need to be updated (and sorry for not noticing it earlier). -- Vitaly ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v4 1/5] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit 2020-03-10 16:55 ` Vitaly Kuznetsov @ 2020-03-10 17:14 ` Jon Doron 0 siblings, 0 replies; 18+ messages in thread From: Jon Doron @ 2020-03-10 17:14 UTC (permalink / raw) To: Vitaly Kuznetsov; +Cc: kvm, linux-hyperv On 10/03/2020, Vitaly Kuznetsov wrote: >Jon Doron <arilou@gmail.com> writes: > >> Signed-off-by: Jon Doron <arilou@gmail.com> >> --- >> include/uapi/linux/kvm.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index 4b95f9a31a2f..7acfd6a2569a 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -189,6 +189,7 @@ struct kvm_hyperv_exit { >> #define KVM_EXIT_HYPERV_SYNIC 1 >> #define KVM_EXIT_HYPERV_HCALL 2 >> __u32 type; >> + __u32 pad; >> union { >> struct { >> __u32 msr; > >Sorry if I missed something but I think the suggestion was to pad this >'msr' too (in case we're aiming at making padding explicit for the whole >structure). Or is there any reason to not do that? > >Also, I just noticed that we have a copy of this definition in >Documentation/virt/kvm/api.rst - it will need to be updated (and sorry >for not noticing it earlier). > >-- >Vitaly > Heh sure no problem will fix in v5, but going to wait for a verdict on the location for the new CPUID leafs and MSRs for the synthetic debugger. -- Jon. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-09 18:20 [PATCH v4 0/5] x86/kvm/hyper-v: add support for synthetic debugger Jon Doron 2020-03-09 18:20 ` [PATCH v4 1/5] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit Jon Doron @ 2020-03-09 18:20 ` Jon Doron 2020-03-09 21:00 ` Michael Kelley 2020-03-09 18:20 ` [PATCH v4 3/5] x86/kvm/hyper-v: Add support for synthetic debugger capability Jon Doron ` (2 subsequent siblings) 4 siblings, 1 reply; 18+ messages in thread From: Jon Doron @ 2020-03-09 18:20 UTC (permalink / raw) To: kvm, linux-hyperv; +Cc: vkuznets, Jon Doron Hyper-V synthetic debugger has two modes, one that uses MSRs and the other that use Hypercalls. Add all the required definitions to both types of synthetic debugger interface. Signed-off-by: Jon Doron <arilou@gmail.com> --- arch/x86/include/asm/hyperv-tlfs.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h index 92abc1e42bfc..12596da95a53 100644 --- a/arch/x86/include/asm/hyperv-tlfs.h +++ b/arch/x86/include/asm/hyperv-tlfs.h @@ -33,6 +33,9 @@ #define HYPERV_CPUID_ENLIGHTMENT_INFO 0x40000004 #define HYPERV_CPUID_IMPLEMENT_LIMITS 0x40000005 #define HYPERV_CPUID_NESTED_FEATURES 0x4000000A +#define HYPERV_CPUID_SYNDBG_VENDOR_AND_MAX_FUNCTIONS 0x40000080 +#define HYPERV_CPUID_SYNDBG_INTERFACE 0x40000081 +#define HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES 0x40000082 #define HYPERV_HYPERVISOR_PRESENT_BIT 0x80000000 #define HYPERV_CPUID_MIN 0x40000005 @@ -131,6 +134,8 @@ #define HV_FEATURE_FREQUENCY_MSRS_AVAILABLE BIT(8) /* Crash MSR available */ #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE BIT(10) +/* Support for debug MSRs available */ +#define HV_FEATURE_DEBUG_MSRS_AVAILABLE BIT(11) /* stimer Direct Mode is available */ #define HV_STIMER_DIRECT_MODE_AVAILABLE BIT(19) @@ -194,6 +199,12 @@ #define HV_X64_NESTED_GUEST_MAPPING_FLUSH BIT(18) #define HV_X64_NESTED_MSR_BITMAP BIT(19) +/* + * Hyper-V synthetic debugger platform capabilities + * These are HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES.EAX bits. + */ +#define HV_X64_SYNDBG_CAP_ALLOW_KERNEL_DEBUGGING BIT(1) + /* Hyper-V specific model specific registers (MSRs) */ /* MSR used to identify the guest OS. */ @@ -267,6 +278,17 @@ /* Hyper-V guest idle MSR */ #define HV_X64_MSR_GUEST_IDLE 0x400000F0 +/* Hyper-V Synthetic debug options MSR */ +#define HV_X64_MSR_SYNDBG_CONTROL 0x400000F1 +#define HV_X64_MSR_SYNDBG_STATUS 0x400000F2 +#define HV_X64_MSR_SYNDBG_SEND_BUFFER 0x400000F3 +#define HV_X64_MSR_SYNDBG_RECV_BUFFER 0x400000F4 +#define HV_X64_MSR_SYNDBG_PENDING_BUFFER 0x400000F5 +#define HV_X64_MSR_SYNDBG_OPTIONS 0x400000FF + +/* Hyper-V HV_X64_MSR_SYNDBG_OPTIONS bits */ +#define HV_X64_SYNDBG_OPTION_USE_HCALLS BIT(2) + /* Hyper-V guest crash notification MSR's */ #define HV_X64_MSR_CRASH_P0 0x40000100 #define HV_X64_MSR_CRASH_P1 0x40000101 @@ -376,6 +398,9 @@ struct hv_tsc_emulation_status { #define HVCALL_SEND_IPI_EX 0x0015 #define HVCALL_POST_MESSAGE 0x005c #define HVCALL_SIGNAL_EVENT 0x005d +#define HVCALL_POST_DEBUG_DATA 0x0069 +#define HVCALL_RETRIEVE_DEBUG_DATA 0x006a +#define HVCALL_RESET_DEBUG_SESSION 0x006b #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0 @@ -419,6 +444,7 @@ enum HV_GENERIC_SET_FORMAT { #define HV_STATUS_INVALID_HYPERCALL_INPUT 3 #define HV_STATUS_INVALID_ALIGNMENT 4 #define HV_STATUS_INVALID_PARAMETER 5 +#define HV_STATUS_OPERATION_DENIED 8 #define HV_STATUS_INSUFFICIENT_MEMORY 11 #define HV_STATUS_INVALID_PORT_ID 17 #define HV_STATUS_INVALID_CONNECTION_ID 18 -- 2.24.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* RE: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-09 18:20 ` [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions Jon Doron @ 2020-03-09 21:00 ` Michael Kelley 2020-03-10 3:24 ` Jon Doron 0 siblings, 1 reply; 18+ messages in thread From: Michael Kelley @ 2020-03-09 21:00 UTC (permalink / raw) To: Jon Doron, kvm, linux-hyperv; +Cc: vkuznets From: Jon Doron <arilou@gmail.com> Sent: Monday, March 9, 2020 11:20 AM > > Hyper-V synthetic debugger has two modes, one that uses MSRs and > the other that use Hypercalls. > > Add all the required definitions to both types of synthetic debugger > interface. > > Signed-off-by: Jon Doron <arilou@gmail.com> I got some additional details from the Hyper-V team about the Hyper-V synthetic debugger functionality. Starting with Windows 10 and Windows Server 2016, KDNET is built-in to the Windows OS. So when these and later Windows versions are running as a guest on KVM, the synthetic debugger support should not be needed. It would only be needed for older Windows versions (Windows 8.1, Windows Server 2012 R2, and earlier) that lack a built-in KDNET. Given the age of these Windows versions, I'm wondering whether having KVM try to emulate Hyper-V's synthetic debugging support is worthwhile. While the synthetic debugger support is still present in current Windows releases along with the built-in KDNET, it is a legacy feature that is subject to being removed at any time in a future release. Also, the debug hypercalls are only offered to the parent partition, so they are undocumented in the TLFS and the interfaces are subject to change at any time. Given the situation, I would rather not have the MSR and CPUID leaf definitions added to hyperv-tlfs.h. But maybe I'm misunderstanding what you are trying to accomplish. Is there a bigger picture of what the goals are for adding the synthetic debugger support? Michael > --- > arch/x86/include/asm/hyperv-tlfs.h | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h > index 92abc1e42bfc..12596da95a53 100644 > --- a/arch/x86/include/asm/hyperv-tlfs.h > +++ b/arch/x86/include/asm/hyperv-tlfs.h > @@ -33,6 +33,9 @@ > #define HYPERV_CPUID_ENLIGHTMENT_INFO 0x40000004 > #define HYPERV_CPUID_IMPLEMENT_LIMITS 0x40000005 > #define HYPERV_CPUID_NESTED_FEATURES 0x4000000A > +#define HYPERV_CPUID_SYNDBG_VENDOR_AND_MAX_FUNCTIONS 0x40000080 > +#define HYPERV_CPUID_SYNDBG_INTERFACE 0x40000081 > +#define HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES 0x40000082 > > #define HYPERV_HYPERVISOR_PRESENT_BIT 0x80000000 > #define HYPERV_CPUID_MIN 0x40000005 > @@ -131,6 +134,8 @@ > #define HV_FEATURE_FREQUENCY_MSRS_AVAILABLE BIT(8) > /* Crash MSR available */ > #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE BIT(10) > +/* Support for debug MSRs available */ > +#define HV_FEATURE_DEBUG_MSRS_AVAILABLE BIT(11) > /* stimer Direct Mode is available */ > #define HV_STIMER_DIRECT_MODE_AVAILABLE BIT(19) > > @@ -194,6 +199,12 @@ > #define HV_X64_NESTED_GUEST_MAPPING_FLUSH BIT(18) > #define HV_X64_NESTED_MSR_BITMAP BIT(19) > > +/* > + * Hyper-V synthetic debugger platform capabilities > + * These are HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES.EAX bits. > + */ > +#define HV_X64_SYNDBG_CAP_ALLOW_KERNEL_DEBUGGING BIT(1) > + > /* Hyper-V specific model specific registers (MSRs) */ > > /* MSR used to identify the guest OS. */ > @@ -267,6 +278,17 @@ > /* Hyper-V guest idle MSR */ > #define HV_X64_MSR_GUEST_IDLE 0x400000F0 > > +/* Hyper-V Synthetic debug options MSR */ > +#define HV_X64_MSR_SYNDBG_CONTROL 0x400000F1 > +#define HV_X64_MSR_SYNDBG_STATUS 0x400000F2 > +#define HV_X64_MSR_SYNDBG_SEND_BUFFER 0x400000F3 > +#define HV_X64_MSR_SYNDBG_RECV_BUFFER 0x400000F4 > +#define HV_X64_MSR_SYNDBG_PENDING_BUFFER 0x400000F5 > +#define HV_X64_MSR_SYNDBG_OPTIONS 0x400000FF > + > +/* Hyper-V HV_X64_MSR_SYNDBG_OPTIONS bits */ > +#define HV_X64_SYNDBG_OPTION_USE_HCALLS BIT(2) > + > /* Hyper-V guest crash notification MSR's */ > #define HV_X64_MSR_CRASH_P0 0x40000100 > #define HV_X64_MSR_CRASH_P1 0x40000101 > @@ -376,6 +398,9 @@ struct hv_tsc_emulation_status { > #define HVCALL_SEND_IPI_EX 0x0015 > #define HVCALL_POST_MESSAGE 0x005c > #define HVCALL_SIGNAL_EVENT 0x005d > +#define HVCALL_POST_DEBUG_DATA 0x0069 > +#define HVCALL_RETRIEVE_DEBUG_DATA 0x006a > +#define HVCALL_RESET_DEBUG_SESSION 0x006b > #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af > #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0 > > @@ -419,6 +444,7 @@ enum HV_GENERIC_SET_FORMAT { > #define HV_STATUS_INVALID_HYPERCALL_INPUT 3 > #define HV_STATUS_INVALID_ALIGNMENT 4 > #define HV_STATUS_INVALID_PARAMETER 5 > +#define HV_STATUS_OPERATION_DENIED 8 > #define HV_STATUS_INSUFFICIENT_MEMORY 11 > #define HV_STATUS_INVALID_PORT_ID 17 > #define HV_STATUS_INVALID_CONNECTION_ID 18 > -- > 2.24.1 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-09 21:00 ` Michael Kelley @ 2020-03-10 3:24 ` Jon Doron 2020-03-10 3:53 ` Michael Kelley 0 siblings, 1 reply; 18+ messages in thread From: Jon Doron @ 2020-03-10 3:24 UTC (permalink / raw) To: Michael Kelley; +Cc: kvm, linux-hyperv, vkuznets On 09/03/2020, Michael Kelley wrote: >From: Jon Doron <arilou@gmail.com> Sent: Monday, March 9, 2020 11:20 AM >> >> Hyper-V synthetic debugger has two modes, one that uses MSRs and >> the other that use Hypercalls. >> >> Add all the required definitions to both types of synthetic debugger >> interface. >> >> Signed-off-by: Jon Doron <arilou@gmail.com> > >I got some additional details from the Hyper-V team about the Hyper-V >synthetic debugger functionality. Starting with Windows 10 and Windows >Server 2016, KDNET is built-in to the Windows OS. So when these and later >Windows versions are running as a guest on KVM, the synthetic debugger >support should not be needed. It would only be needed for older Windows >versions (Windows 8.1, Windows Server 2012 R2, and earlier) that lack a >built-in KDNET. Given the age of these Windows versions, I'm wondering >whether having KVM try to emulate Hyper-V's synthetic debugging support >is worthwhile. While the synthetic debugger support is still present in >current Windows releases along with the built-in KDNET, it is a legacy feature >that is subject to being removed at any time in a future release. Also, the >debug hypercalls are only offered to the parent partition, so they are >undocumented in the TLFS and the interfaces are subject to change at any >time. > >Given the situation, I would rather not have the MSR and CPUID leaf definitions >added to hyperv-tlfs.h. But maybe I'm misunderstanding what you are trying >to accomplish. Is there a bigger picture of what the goals are for adding the >synthetic debugger support? > >Michael > Hi Michael, thank you for getting back on this, the goal of this is to allow fast kernel debugging mainly for the older OSs, without the synthetic kernel debugger you must opt-in to serial which is pretty "painful" when it comes to debugging. With that said it sounds like I need to look into setting up KDNet with KVM, might be trivial I have not tried it yet, but in general KDNet support only a small set of network adapters. (https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/supported-ethernet-nics-for-network-kernel-debugging-in-windows-8-1) As for the hypercalls, it's just something I ran into, I dont mind dropping off the hypercall interface (since the MSRs are way faster and simpler anyway, as I dont need to deal with UDP encapsulation. In case you end up insisting I'll remove the MSR and CPUID leaf definitions what would be the workaround to implement the syndbg functionality? Thanks, -- Jon. >> --- >> arch/x86/include/asm/hyperv-tlfs.h | 26 ++++++++++++++++++++++++++ >> 1 file changed, 26 insertions(+) >> >> diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h >> index 92abc1e42bfc..12596da95a53 100644 >> --- a/arch/x86/include/asm/hyperv-tlfs.h >> +++ b/arch/x86/include/asm/hyperv-tlfs.h >> @@ -33,6 +33,9 @@ >> #define HYPERV_CPUID_ENLIGHTMENT_INFO 0x40000004 >> #define HYPERV_CPUID_IMPLEMENT_LIMITS 0x40000005 >> #define HYPERV_CPUID_NESTED_FEATURES 0x4000000A >> +#define HYPERV_CPUID_SYNDBG_VENDOR_AND_MAX_FUNCTIONS 0x40000080 >> +#define HYPERV_CPUID_SYNDBG_INTERFACE 0x40000081 >> +#define HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES 0x40000082 >> >> #define HYPERV_HYPERVISOR_PRESENT_BIT 0x80000000 >> #define HYPERV_CPUID_MIN 0x40000005 >> @@ -131,6 +134,8 @@ >> #define HV_FEATURE_FREQUENCY_MSRS_AVAILABLE BIT(8) >> /* Crash MSR available */ >> #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE BIT(10) >> +/* Support for debug MSRs available */ >> +#define HV_FEATURE_DEBUG_MSRS_AVAILABLE BIT(11) >> /* stimer Direct Mode is available */ >> #define HV_STIMER_DIRECT_MODE_AVAILABLE BIT(19) >> >> @@ -194,6 +199,12 @@ >> #define HV_X64_NESTED_GUEST_MAPPING_FLUSH BIT(18) >> #define HV_X64_NESTED_MSR_BITMAP BIT(19) >> >> +/* >> + * Hyper-V synthetic debugger platform capabilities >> + * These are HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES.EAX bits. >> + */ >> +#define HV_X64_SYNDBG_CAP_ALLOW_KERNEL_DEBUGGING BIT(1) >> + >> /* Hyper-V specific model specific registers (MSRs) */ >> >> /* MSR used to identify the guest OS. */ >> @@ -267,6 +278,17 @@ >> /* Hyper-V guest idle MSR */ >> #define HV_X64_MSR_GUEST_IDLE 0x400000F0 >> >> +/* Hyper-V Synthetic debug options MSR */ >> +#define HV_X64_MSR_SYNDBG_CONTROL 0x400000F1 >> +#define HV_X64_MSR_SYNDBG_STATUS 0x400000F2 >> +#define HV_X64_MSR_SYNDBG_SEND_BUFFER 0x400000F3 >> +#define HV_X64_MSR_SYNDBG_RECV_BUFFER 0x400000F4 >> +#define HV_X64_MSR_SYNDBG_PENDING_BUFFER 0x400000F5 >> +#define HV_X64_MSR_SYNDBG_OPTIONS 0x400000FF >> + >> +/* Hyper-V HV_X64_MSR_SYNDBG_OPTIONS bits */ >> +#define HV_X64_SYNDBG_OPTION_USE_HCALLS BIT(2) >> + >> /* Hyper-V guest crash notification MSR's */ >> #define HV_X64_MSR_CRASH_P0 0x40000100 >> #define HV_X64_MSR_CRASH_P1 0x40000101 >> @@ -376,6 +398,9 @@ struct hv_tsc_emulation_status { >> #define HVCALL_SEND_IPI_EX 0x0015 >> #define HVCALL_POST_MESSAGE 0x005c >> #define HVCALL_SIGNAL_EVENT 0x005d >> +#define HVCALL_POST_DEBUG_DATA 0x0069 >> +#define HVCALL_RETRIEVE_DEBUG_DATA 0x006a >> +#define HVCALL_RESET_DEBUG_SESSION 0x006b >> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af >> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0 >> >> @@ -419,6 +444,7 @@ enum HV_GENERIC_SET_FORMAT { >> #define HV_STATUS_INVALID_HYPERCALL_INPUT 3 >> #define HV_STATUS_INVALID_ALIGNMENT 4 >> #define HV_STATUS_INVALID_PARAMETER 5 >> +#define HV_STATUS_OPERATION_DENIED 8 >> #define HV_STATUS_INSUFFICIENT_MEMORY 11 >> #define HV_STATUS_INVALID_PORT_ID 17 >> #define HV_STATUS_INVALID_CONNECTION_ID 18 >> -- >> 2.24.1 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-10 3:24 ` Jon Doron @ 2020-03-10 3:53 ` Michael Kelley 2020-03-10 4:28 ` Jon Doron ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Michael Kelley @ 2020-03-10 3:53 UTC (permalink / raw) To: Jon Doron; +Cc: kvm, linux-hyperv, vkuznets From: Jon Doron <arilou@gmail.com> Sent: Monday, March 9, 2020 8:25 PM > > On 09/03/2020, Michael Kelley wrote: > >From: Jon Doron <arilou@gmail.com> Sent: Monday, March 9, 2020 11:20 AM > >> > >> Hyper-V synthetic debugger has two modes, one that uses MSRs and > >> the other that use Hypercalls. > >> > >> Add all the required definitions to both types of synthetic debugger > >> interface. > >> > >> Signed-off-by: Jon Doron <arilou@gmail.com> > > > >I got some additional details from the Hyper-V team about the Hyper-V > >synthetic debugger functionality. Starting with Windows 10 and Windows > >Server 2016, KDNET is built-in to the Windows OS. So when these and later > >Windows versions are running as a guest on KVM, the synthetic debugger > >support should not be needed. It would only be needed for older Windows > >versions (Windows 8.1, Windows Server 2012 R2, and earlier) that lack a > >built-in KDNET. Given the age of these Windows versions, I'm wondering > >whether having KVM try to emulate Hyper-V's synthetic debugging support > >is worthwhile. While the synthetic debugger support is still present in > >current Windows releases along with the built-in KDNET, it is a legacy feature > >that is subject to being removed at any time in a future release. Also, the > >debug hypercalls are only offered to the parent partition, so they are > >undocumented in the TLFS and the interfaces are subject to change at any > >time. > > > >Given the situation, I would rather not have the MSR and CPUID leaf definitions > >added to hyperv-tlfs.h. But maybe I'm misunderstanding what you are trying > >to accomplish. Is there a bigger picture of what the goals are for adding the > >synthetic debugger support? > > > >Michael > > > > Hi Michael, thank you for getting back on this, the goal of this is to > allow fast kernel debugging mainly for the older OSs, without the > synthetic kernel debugger you must opt-in to serial which is pretty > "painful" when it comes to debugging. OK, so you really are targeting the older Windows OS versions. > > With that said it sounds like I need to look into setting up KDNet with > KVM, might be trivial I have not tried it yet, but in general KDNet > support only a small set of network adapters. > (https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/supported-ethernet-nics-for-network-kernel-debugging-in-windows-8-1) > I don't know my vendor IDs and device IDs very well. Are there commonly used network adapters that aren't on the list? I'm asking just out of curiosity .... > As for the hypercalls, it's just something I ran into, I dont mind > dropping off the hypercall interface (since the MSRs are way faster and > simpler anyway, as I dont need to deal with UDP encapsulation. > > In case you end up insisting I'll remove the MSR and CPUID leaf > definitions what would be the workaround to implement the syndbg functionality? I'm flexible, and trying to not be a pain-in-the-neck. :-) What would the KVM guys think about putting the definitions in a KVM specific #include file, and clearly marking them as deprecated, mostly undocumented, and used only to support debugging old Windows versions? Michael > > Thanks, > -- Jon. > > >> --- > >> arch/x86/include/asm/hyperv-tlfs.h | 26 ++++++++++++++++++++++++++ > >> 1 file changed, 26 insertions(+) > >> > >> diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h > >> index 92abc1e42bfc..12596da95a53 100644 > >> --- a/arch/x86/include/asm/hyperv-tlfs.h > >> +++ b/arch/x86/include/asm/hyperv-tlfs.h > >> @@ -33,6 +33,9 @@ > >> #define HYPERV_CPUID_ENLIGHTMENT_INFO 0x40000004 > >> #define HYPERV_CPUID_IMPLEMENT_LIMITS 0x40000005 > >> #define HYPERV_CPUID_NESTED_FEATURES 0x4000000A > >> +#define HYPERV_CPUID_SYNDBG_VENDOR_AND_MAX_FUNCTIONS 0x40000080 > >> +#define HYPERV_CPUID_SYNDBG_INTERFACE 0x40000081 > >> +#define HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES 0x40000082 > >> > >> #define HYPERV_HYPERVISOR_PRESENT_BIT 0x80000000 > >> #define HYPERV_CPUID_MIN 0x40000005 > >> @@ -131,6 +134,8 @@ > >> #define HV_FEATURE_FREQUENCY_MSRS_AVAILABLE BIT(8) > >> /* Crash MSR available */ > >> #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE BIT(10) > >> +/* Support for debug MSRs available */ > >> +#define HV_FEATURE_DEBUG_MSRS_AVAILABLE BIT(11) > >> /* stimer Direct Mode is available */ > >> #define HV_STIMER_DIRECT_MODE_AVAILABLE BIT(19) > >> > >> @@ -194,6 +199,12 @@ > >> #define HV_X64_NESTED_GUEST_MAPPING_FLUSH BIT(18) > >> #define HV_X64_NESTED_MSR_BITMAP BIT(19) > >> > >> +/* > >> + * Hyper-V synthetic debugger platform capabilities > >> + * These are HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES.EAX bits. > >> + */ > >> +#define HV_X64_SYNDBG_CAP_ALLOW_KERNEL_DEBUGGING BIT(1) > >> + > >> /* Hyper-V specific model specific registers (MSRs) */ > >> > >> /* MSR used to identify the guest OS. */ > >> @@ -267,6 +278,17 @@ > >> /* Hyper-V guest idle MSR */ > >> #define HV_X64_MSR_GUEST_IDLE 0x400000F0 > >> > >> +/* Hyper-V Synthetic debug options MSR */ > >> +#define HV_X64_MSR_SYNDBG_CONTROL 0x400000F1 > >> +#define HV_X64_MSR_SYNDBG_STATUS 0x400000F2 > >> +#define HV_X64_MSR_SYNDBG_SEND_BUFFER 0x400000F3 > >> +#define HV_X64_MSR_SYNDBG_RECV_BUFFER 0x400000F4 > >> +#define HV_X64_MSR_SYNDBG_PENDING_BUFFER 0x400000F5 > >> +#define HV_X64_MSR_SYNDBG_OPTIONS 0x400000FF > >> + > >> +/* Hyper-V HV_X64_MSR_SYNDBG_OPTIONS bits */ > >> +#define HV_X64_SYNDBG_OPTION_USE_HCALLS BIT(2) > >> + > >> /* Hyper-V guest crash notification MSR's */ > >> #define HV_X64_MSR_CRASH_P0 0x40000100 > >> #define HV_X64_MSR_CRASH_P1 0x40000101 > >> @@ -376,6 +398,9 @@ struct hv_tsc_emulation_status { > >> #define HVCALL_SEND_IPI_EX 0x0015 > >> #define HVCALL_POST_MESSAGE 0x005c > >> #define HVCALL_SIGNAL_EVENT 0x005d > >> +#define HVCALL_POST_DEBUG_DATA 0x0069 > >> +#define HVCALL_RETRIEVE_DEBUG_DATA 0x006a > >> +#define HVCALL_RESET_DEBUG_SESSION 0x006b > >> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af > >> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0 > >> > >> @@ -419,6 +444,7 @@ enum HV_GENERIC_SET_FORMAT { > >> #define HV_STATUS_INVALID_HYPERCALL_INPUT 3 > >> #define HV_STATUS_INVALID_ALIGNMENT 4 > >> #define HV_STATUS_INVALID_PARAMETER 5 > >> +#define HV_STATUS_OPERATION_DENIED 8 > >> #define HV_STATUS_INSUFFICIENT_MEMORY 11 > >> #define HV_STATUS_INVALID_PORT_ID 17 > >> #define HV_STATUS_INVALID_CONNECTION_ID 18 > >> -- > >> 2.24.1 > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-10 3:53 ` Michael Kelley @ 2020-03-10 4:28 ` Jon Doron 2020-03-10 14:23 ` Wei Liu 2020-03-12 13:51 ` Vitaly Kuznetsov 2 siblings, 0 replies; 18+ messages in thread From: Jon Doron @ 2020-03-10 4:28 UTC (permalink / raw) To: Michael Kelley; +Cc: kvm, linux-hyperv, vkuznets On 10/03/2020, Michael Kelley wrote: >From: Jon Doron <arilou@gmail.com> Sent: Monday, March 9, 2020 8:25 PM >> >> On 09/03/2020, Michael Kelley wrote: >> >From: Jon Doron <arilou@gmail.com> Sent: Monday, March 9, 2020 11:20 AM >> >> >> >> Hyper-V synthetic debugger has two modes, one that uses MSRs and >> >> the other that use Hypercalls. >> >> >> >> Add all the required definitions to both types of synthetic debugger >> >> interface. >> >> >> >> Signed-off-by: Jon Doron <arilou@gmail.com> >> > >> >I got some additional details from the Hyper-V team about the Hyper-V >> >synthetic debugger functionality. Starting with Windows 10 and Windows >> >Server 2016, KDNET is built-in to the Windows OS. So when these and later >> >Windows versions are running as a guest on KVM, the synthetic debugger >> >support should not be needed. It would only be needed for older Windows >> >versions (Windows 8.1, Windows Server 2012 R2, and earlier) that lack a >> >built-in KDNET. Given the age of these Windows versions, I'm wondering >> >whether having KVM try to emulate Hyper-V's synthetic debugging support >> >is worthwhile. While the synthetic debugger support is still present in >> >current Windows releases along with the built-in KDNET, it is a legacy feature >> >that is subject to being removed at any time in a future release. Also, the >> >debug hypercalls are only offered to the parent partition, so they are >> >undocumented in the TLFS and the interfaces are subject to change at any >> >time. >> > >> >Given the situation, I would rather not have the MSR and CPUID leaf definitions >> >added to hyperv-tlfs.h. But maybe I'm misunderstanding what you are trying >> >to accomplish. Is there a bigger picture of what the goals are for adding the >> >synthetic debugger support? >> > >> >Michael >> > >> >> Hi Michael, thank you for getting back on this, the goal of this is to >> allow fast kernel debugging mainly for the older OSs, without the >> synthetic kernel debugger you must opt-in to serial which is pretty >> "painful" when it comes to debugging. > >OK, so you really are targeting the older Windows OS versions. > Right. :) >> >> With that said it sounds like I need to look into setting up KDNet with >> KVM, might be trivial I have not tried it yet, but in general KDNet >> support only a small set of network adapters. >> (https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/supported-ethernet-nics-for-network-kernel-debugging-in-windows-8-1) >> > >I don't know my vendor IDs and device IDs very well. Are there >commonly used network adapters that aren't on the list? I'm asking >just out of curiosity .... > Well I did further look into this now and it seems like the e1000e should work did find a recent case which indicates there was an issue until not too long ago: https://bugzilla.redhat.com/show_bug.cgi?id=1787142 I'll try to bring up a setup with the latest Win10 and see if I can configure it for kernel debugging via e1000e nic. >> As for the hypercalls, it's just something I ran into, I dont mind >> dropping off the hypercall interface (since the MSRs are way faster and >> simpler anyway, as I dont need to deal with UDP encapsulation. >> >> In case you end up insisting I'll remove the MSR and CPUID leaf >> definitions what would be the workaround to implement the syndbg functionality? > >I'm flexible, and trying to not be a pain-in-the-neck. :-) What would >the KVM guys think about putting the definitions in a KVM specific >#include file, and clearly marking them as deprecated, mostly >undocumented, and used only to support debugging old Windows >versions? > >Michael > >> >> Thanks, >> -- Jon. >> >> >> --- >> >> arch/x86/include/asm/hyperv-tlfs.h | 26 ++++++++++++++++++++++++++ >> >> 1 file changed, 26 insertions(+) >> >> >> >> diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h >> >> index 92abc1e42bfc..12596da95a53 100644 >> >> --- a/arch/x86/include/asm/hyperv-tlfs.h >> >> +++ b/arch/x86/include/asm/hyperv-tlfs.h >> >> @@ -33,6 +33,9 @@ >> >> #define HYPERV_CPUID_ENLIGHTMENT_INFO 0x40000004 >> >> #define HYPERV_CPUID_IMPLEMENT_LIMITS 0x40000005 >> >> #define HYPERV_CPUID_NESTED_FEATURES 0x4000000A >> >> +#define HYPERV_CPUID_SYNDBG_VENDOR_AND_MAX_FUNCTIONS 0x40000080 >> >> +#define HYPERV_CPUID_SYNDBG_INTERFACE 0x40000081 >> >> +#define HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES 0x40000082 >> >> >> >> #define HYPERV_HYPERVISOR_PRESENT_BIT 0x80000000 >> >> #define HYPERV_CPUID_MIN 0x40000005 >> >> @@ -131,6 +134,8 @@ >> >> #define HV_FEATURE_FREQUENCY_MSRS_AVAILABLE BIT(8) >> >> /* Crash MSR available */ >> >> #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE BIT(10) >> >> +/* Support for debug MSRs available */ >> >> +#define HV_FEATURE_DEBUG_MSRS_AVAILABLE BIT(11) >> >> /* stimer Direct Mode is available */ >> >> #define HV_STIMER_DIRECT_MODE_AVAILABLE BIT(19) >> >> >> >> @@ -194,6 +199,12 @@ >> >> #define HV_X64_NESTED_GUEST_MAPPING_FLUSH BIT(18) >> >> #define HV_X64_NESTED_MSR_BITMAP BIT(19) >> >> >> >> +/* >> >> + * Hyper-V synthetic debugger platform capabilities >> >> + * These are HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES.EAX bits. >> >> + */ >> >> +#define HV_X64_SYNDBG_CAP_ALLOW_KERNEL_DEBUGGING BIT(1) >> >> + >> >> /* Hyper-V specific model specific registers (MSRs) */ >> >> >> >> /* MSR used to identify the guest OS. */ >> >> @@ -267,6 +278,17 @@ >> >> /* Hyper-V guest idle MSR */ >> >> #define HV_X64_MSR_GUEST_IDLE 0x400000F0 >> >> >> >> +/* Hyper-V Synthetic debug options MSR */ >> >> +#define HV_X64_MSR_SYNDBG_CONTROL 0x400000F1 >> >> +#define HV_X64_MSR_SYNDBG_STATUS 0x400000F2 >> >> +#define HV_X64_MSR_SYNDBG_SEND_BUFFER 0x400000F3 >> >> +#define HV_X64_MSR_SYNDBG_RECV_BUFFER 0x400000F4 >> >> +#define HV_X64_MSR_SYNDBG_PENDING_BUFFER 0x400000F5 >> >> +#define HV_X64_MSR_SYNDBG_OPTIONS 0x400000FF >> >> + >> >> +/* Hyper-V HV_X64_MSR_SYNDBG_OPTIONS bits */ >> >> +#define HV_X64_SYNDBG_OPTION_USE_HCALLS BIT(2) >> >> + >> >> /* Hyper-V guest crash notification MSR's */ >> >> #define HV_X64_MSR_CRASH_P0 0x40000100 >> >> #define HV_X64_MSR_CRASH_P1 0x40000101 >> >> @@ -376,6 +398,9 @@ struct hv_tsc_emulation_status { >> >> #define HVCALL_SEND_IPI_EX 0x0015 >> >> #define HVCALL_POST_MESSAGE 0x005c >> >> #define HVCALL_SIGNAL_EVENT 0x005d >> >> +#define HVCALL_POST_DEBUG_DATA 0x0069 >> >> +#define HVCALL_RETRIEVE_DEBUG_DATA 0x006a >> >> +#define HVCALL_RESET_DEBUG_SESSION 0x006b >> >> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af >> >> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0 >> >> >> >> @@ -419,6 +444,7 @@ enum HV_GENERIC_SET_FORMAT { >> >> #define HV_STATUS_INVALID_HYPERCALL_INPUT 3 >> >> #define HV_STATUS_INVALID_ALIGNMENT 4 >> >> #define HV_STATUS_INVALID_PARAMETER 5 >> >> +#define HV_STATUS_OPERATION_DENIED 8 >> >> #define HV_STATUS_INSUFFICIENT_MEMORY 11 >> >> #define HV_STATUS_INVALID_PORT_ID 17 >> >> #define HV_STATUS_INVALID_CONNECTION_ID 18 >> >> -- >> >> 2.24.1 >> > Thanks, -- Jon. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-10 3:53 ` Michael Kelley 2020-03-10 4:28 ` Jon Doron @ 2020-03-10 14:23 ` Wei Liu 2020-03-12 13:51 ` Vitaly Kuznetsov 2 siblings, 0 replies; 18+ messages in thread From: Wei Liu @ 2020-03-10 14:23 UTC (permalink / raw) To: Michael Kelley; +Cc: Jon Doron, kvm, linux-hyperv, vkuznets, Wei Liu On Tue, Mar 10, 2020 at 03:53:06AM +0000, Michael Kelley wrote: [...] > > > > In case you end up insisting I'll remove the MSR and CPUID leaf > > definitions what would be the workaround to implement the syndbg functionality? > > I'm flexible, and trying to not be a pain-in-the-neck. :-) What would > the KVM guys think about putting the definitions in a KVM specific > #include file, and clearly marking them as deprecated, mostly > undocumented, and used only to support debugging old Windows > versions? > +1 for this. Wei. ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-10 3:53 ` Michael Kelley 2020-03-10 4:28 ` Jon Doron 2020-03-10 14:23 ` Wei Liu @ 2020-03-12 13:51 ` Vitaly Kuznetsov 2020-03-12 14:59 ` Michael Kelley 2 siblings, 1 reply; 18+ messages in thread From: Vitaly Kuznetsov @ 2020-03-12 13:51 UTC (permalink / raw) To: Michael Kelley, Jon Doron, Wei Liu; +Cc: kvm, linux-hyperv Michael Kelley <mikelley@microsoft.com> writes: > I'm flexible, and trying to not be a pain-in-the-neck. :-) What would > the KVM guys think about putting the definitions in a KVM specific > #include file, and clearly marking them as deprecated, mostly > undocumented, and used only to support debugging old Windows > versions? I *think* we should do the following: defines which *are* present in TLFS doc (e.g. HV_FEATURE_DEBUG_MSRS_AVAILABLE, HV_STATUS_OPERATION_DENIED, ...) go to asm/hyperv-tlfs.h, the rest (syndbg) stuff goes to kvm-specific include (I'd suggest we just use hyperv.h we already have). What do you think? -- Vitaly ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-12 13:51 ` Vitaly Kuznetsov @ 2020-03-12 14:59 ` Michael Kelley 2020-03-12 19:12 ` Jon Doron 0 siblings, 1 reply; 18+ messages in thread From: Michael Kelley @ 2020-03-12 14:59 UTC (permalink / raw) To: vkuznets, Jon Doron, Wei Liu; +Cc: kvm, linux-hyperv From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Thursday, March 12, 2020 6:51 AM > > Michael Kelley <mikelley@microsoft.com> writes: > > > I'm flexible, and trying to not be a pain-in-the-neck. :-) What would > > the KVM guys think about putting the definitions in a KVM specific > > #include file, and clearly marking them as deprecated, mostly > > undocumented, and used only to support debugging old Windows > > versions? > > I *think* we should do the following: defines which *are* present in > TLFS doc (e.g. HV_FEATURE_DEBUG_MSRS_AVAILABLE, > HV_STATUS_OPERATION_DENIED, ...) go to asm/hyperv-tlfs.h, the rest > (syndbg) stuff goes to kvm-specific include (I'd suggest we just use > hyperv.h we already have). > > What do you think? > I could live with this proposal, since they *are* in the TLFS v6.0 as it exists today. However, v6.0 seems inconsistent in what parts of this debugging functionality it exposes, probably just because someone hasn't thought comprehensively about the topic across the whole document. I'll make sure that it gets looked at in the next revision (which should be a lot sooner that the 2+ years it took to get the v6.0 revision done). But I won't be surprised if the remaining vestiges are removed at that time, in which case we would want to move the definitions from hyperv-tlfs.h to KVM's hyper.h. Michael ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-12 14:59 ` Michael Kelley @ 2020-03-12 19:12 ` Jon Doron 2020-03-12 19:32 ` Michael Kelley 0 siblings, 1 reply; 18+ messages in thread From: Jon Doron @ 2020-03-12 19:12 UTC (permalink / raw) To: Michael Kelley; +Cc: vkuznets, Wei Liu, kvm, linux-hyperv On 12/03/2020, Michael Kelley wrote: >From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Thursday, March 12, 2020 6:51 AM >> >> Michael Kelley <mikelley@microsoft.com> writes: >> >> > I'm flexible, and trying to not be a pain-in-the-neck. :-) What would >> > the KVM guys think about putting the definitions in a KVM specific >> > #include file, and clearly marking them as deprecated, mostly >> > undocumented, and used only to support debugging old Windows >> > versions? >> >> I *think* we should do the following: defines which *are* present in >> TLFS doc (e.g. HV_FEATURE_DEBUG_MSRS_AVAILABLE, >> HV_STATUS_OPERATION_DENIED, ...) go to asm/hyperv-tlfs.h, the rest >> (syndbg) stuff goes to kvm-specific include (I'd suggest we just use >> hyperv.h we already have). >> >> What do you think? >> > >I could live with this proposal, since they *are* in the TLFS v6.0 as it >exists today. However, v6.0 seems inconsistent in what parts of this >debugging functionality it exposes, probably just because someone >hasn't thought comprehensively about the topic across the whole >document. I'll make sure that it gets looked at in the next revision >(which should be a lot sooner that the 2+ years it took to get the v6.0 >revision done). But I won't be surprised if the remaining vestiges are >removed at that time, in which case we would want to move the >definitions from hyperv-tlfs.h to KVM's hyper.h. > >Michael Hi guys, just a quick note I went over the old HyperV TLFS and it seems like all the Syndbg MSRs are documented (under Appendix F: Hypervisor Synthetic MSRs, from v5.0b). It seems like the undocumented stuff is HV_X64_MSR_SYNDBG_OPTIONS which seems kinda odd because that's how you enable the hypercalls debugging interface which is documented. And the syndbg CPUID leafs are not documented as well. So would you like me to put all the MSRs in the tlfs omitting the HV_X64_MSR_SYNDBG_OPTIONS. So in hyperv.h we will have HV_X64_MSR_SYNDBG_OPTIONS and the CPUID leafs. Thanks in advance, -- Jon. ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-12 19:12 ` Jon Doron @ 2020-03-12 19:32 ` Michael Kelley 2020-03-12 19:34 ` Jon Doron 0 siblings, 1 reply; 18+ messages in thread From: Michael Kelley @ 2020-03-12 19:32 UTC (permalink / raw) To: Jon Doron; +Cc: vkuznets, Wei Liu, kvm, linux-hyperv From: Jon Doron <arilou@gmail.com> Sent: Thursday, March 12, 2020 12:12 PM > > On 12/03/2020, Michael Kelley wrote: > >From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Thursday, March 12, 2020 6:51 AM > >> > >> Michael Kelley <mikelley@microsoft.com> writes: > >> > >> > I'm flexible, and trying to not be a pain-in-the-neck. :-) What would > >> > the KVM guys think about putting the definitions in a KVM specific > >> > #include file, and clearly marking them as deprecated, mostly > >> > undocumented, and used only to support debugging old Windows > >> > versions? > >> > >> I *think* we should do the following: defines which *are* present in > >> TLFS doc (e.g. HV_FEATURE_DEBUG_MSRS_AVAILABLE, > >> HV_STATUS_OPERATION_DENIED, ...) go to asm/hyperv-tlfs.h, the rest > >> (syndbg) stuff goes to kvm-specific include (I'd suggest we just use > >> hyperv.h we already have). > >> > >> What do you think? > >> > > > >I could live with this proposal, since they *are* in the TLFS v6.0 as it > >exists today. However, v6.0 seems inconsistent in what parts of this > >debugging functionality it exposes, probably just because someone > >hasn't thought comprehensively about the topic across the whole > >document. I'll make sure that it gets looked at in the next revision > >(which should be a lot sooner that the 2+ years it took to get the v6.0 > >revision done). But I won't be surprised if the remaining vestiges are > >removed at that time, in which case we would want to move the > >definitions from hyperv-tlfs.h to KVM's hyper.h. > > > >Michael > > Hi guys, just a quick note I went over the old HyperV TLFS and it seems > like all the Syndbg MSRs are documented (under Appendix F: Hypervisor > Synthetic MSRs, from v5.0b). > > It seems like the undocumented stuff is HV_X64_MSR_SYNDBG_OPTIONS which > seems kinda odd because that's how you enable the hypercalls debugging > interface which is documented. > > And the syndbg CPUID leafs are not documented as well. > > So would you like me to put all the MSRs in the tlfs omitting the > HV_X64_MSR_SYNDBG_OPTIONS. > > So in hyperv.h we will have HV_X64_MSR_SYNDBG_OPTIONS and the CPUID > leafs. > Could you make the decision based on the new v6.0 of the Hyper-V TLFS? See https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs to get a copy. I think some of the synthetic debugger stuff has been dropped from the v6.0 version compared with the earlier v5.0 versions, and I'd like the updates to hyperv-tlfs.h to reflect that newest version. Michael ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions 2020-03-12 19:32 ` Michael Kelley @ 2020-03-12 19:34 ` Jon Doron 0 siblings, 0 replies; 18+ messages in thread From: Jon Doron @ 2020-03-12 19:34 UTC (permalink / raw) To: Michael Kelley; +Cc: vkuznets, Wei Liu, kvm, linux-hyperv Sure thing On Thu, Mar 12, 2020 at 9:32 PM Michael Kelley <mikelley@microsoft.com> wrote: > > From: Jon Doron <arilou@gmail.com> Sent: Thursday, March 12, 2020 12:12 PM > > > > On 12/03/2020, Michael Kelley wrote: > > >From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Thursday, March 12, 2020 6:51 AM > > >> > > >> Michael Kelley <mikelley@microsoft.com> writes: > > >> > > >> > I'm flexible, and trying to not be a pain-in-the-neck. :-) What would > > >> > the KVM guys think about putting the definitions in a KVM specific > > >> > #include file, and clearly marking them as deprecated, mostly > > >> > undocumented, and used only to support debugging old Windows > > >> > versions? > > >> > > >> I *think* we should do the following: defines which *are* present in > > >> TLFS doc (e.g. HV_FEATURE_DEBUG_MSRS_AVAILABLE, > > >> HV_STATUS_OPERATION_DENIED, ...) go to asm/hyperv-tlfs.h, the rest > > >> (syndbg) stuff goes to kvm-specific include (I'd suggest we just use > > >> hyperv.h we already have). > > >> > > >> What do you think? > > >> > > > > > >I could live with this proposal, since they *are* in the TLFS v6.0 as it > > >exists today. However, v6.0 seems inconsistent in what parts of this > > >debugging functionality it exposes, probably just because someone > > >hasn't thought comprehensively about the topic across the whole > > >document. I'll make sure that it gets looked at in the next revision > > >(which should be a lot sooner that the 2+ years it took to get the v6.0 > > >revision done). But I won't be surprised if the remaining vestiges are > > >removed at that time, in which case we would want to move the > > >definitions from hyperv-tlfs.h to KVM's hyper.h. > > > > > >Michael > > > > Hi guys, just a quick note I went over the old HyperV TLFS and it seems > > like all the Syndbg MSRs are documented (under Appendix F: Hypervisor > > Synthetic MSRs, from v5.0b). > > > > It seems like the undocumented stuff is HV_X64_MSR_SYNDBG_OPTIONS which > > seems kinda odd because that's how you enable the hypercalls debugging > > interface which is documented. > > > > And the syndbg CPUID leafs are not documented as well. > > > > So would you like me to put all the MSRs in the tlfs omitting the > > HV_X64_MSR_SYNDBG_OPTIONS. > > > > So in hyperv.h we will have HV_X64_MSR_SYNDBG_OPTIONS and the CPUID > > leafs. > > > > Could you make the decision based on the new v6.0 of the Hyper-V TLFS? > See https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs > to get a copy. I think some of the synthetic debugger stuff has been dropped > from the v6.0 version compared with the earlier v5.0 versions, and I'd like the > updates to hyperv-tlfs.h to reflect that newest version. > > Michael ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v4 3/5] x86/kvm/hyper-v: Add support for synthetic debugger capability 2020-03-09 18:20 [PATCH v4 0/5] x86/kvm/hyper-v: add support for synthetic debugger Jon Doron 2020-03-09 18:20 ` [PATCH v4 1/5] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit Jon Doron 2020-03-09 18:20 ` [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions Jon Doron @ 2020-03-09 18:20 ` Jon Doron 2020-03-09 18:20 ` [PATCH v4 4/5] x86/kvm/hyper-v: enable hypercalls regardless of hypercall page Jon Doron 2020-03-09 18:20 ` [PATCH v4 5/5] x86/kvm/hyper-v: Add support for synthetic debugger via hypercalls Jon Doron 4 siblings, 0 replies; 18+ messages in thread From: Jon Doron @ 2020-03-09 18:20 UTC (permalink / raw) To: kvm, linux-hyperv; +Cc: vkuznets, Jon Doron Add support for Hyper-V synthetic debugger (syndbg) interface. The syndbg interface is using MSRs to emulate a way to send/recv packets data. The debug transport dll (kdvm/kdnet) will identify if Hyper-V is enabled and if it supports the synthetic debugger interface it will attempt to use it, instead of trying to initialize a network adapter. Signed-off-by: Jon Doron <arilou@gmail.com> --- arch/x86/include/asm/kvm_host.h | 13 +++ arch/x86/kvm/hyperv.c | 135 +++++++++++++++++++++++++++++++- arch/x86/kvm/hyperv.h | 5 ++ arch/x86/kvm/trace.h | 51 ++++++++++++ arch/x86/kvm/x86.c | 9 +++ include/uapi/linux/kvm.h | 10 +++ 6 files changed, 222 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 98959e8cd448..f8e58e8866bb 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -854,6 +854,18 @@ struct kvm_apic_map { struct kvm_lapic *phys_map[]; }; +/* Hyper-V synthetic debugger (SynDbg)*/ +struct kvm_hv_syndbg { + struct { + u64 control; + u64 status; + u64 send_page; + u64 recv_page; + u64 pending_page; + } control; + u64 options; +}; + /* Hyper-V emulation context */ struct kvm_hv { struct mutex hv_lock; @@ -877,6 +889,7 @@ struct kvm_hv { atomic_t num_mismatched_vp_indexes; struct hv_partition_assist_pg *hv_pa_pg; + struct kvm_hv_syndbg hv_syndbg; }; enum kvm_irqchip_mode { diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index a86fda7a1d03..b6a97abe2bc9 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -266,6 +266,107 @@ static int synic_set_msr(struct kvm_vcpu_hv_synic *synic, return ret; } +static int kvm_hv_syndbg_complete_userspace(struct kvm_vcpu *vcpu) +{ + struct kvm *kvm = vcpu->kvm; + struct kvm_hv *hv = &kvm->arch.hyperv; + + if (vcpu->run->hyperv.u.syndbg.msr == HV_X64_MSR_SYNDBG_CONTROL) + hv->hv_syndbg.control.status = + vcpu->run->hyperv.u.syndbg.status; + return 1; +} + +static void syndbg_exit(struct kvm_vcpu *vcpu, u32 msr) +{ + struct kvm_hv_syndbg *syndbg = vcpu_to_hv_syndbg(vcpu); + struct kvm_vcpu_hv *hv_vcpu = &vcpu->arch.hyperv; + + hv_vcpu->exit.type = KVM_EXIT_HYPERV_SYNDBG; + hv_vcpu->exit.u.syndbg.msr = msr; + hv_vcpu->exit.u.syndbg.control = syndbg->control.control; + hv_vcpu->exit.u.syndbg.send_page = syndbg->control.send_page; + hv_vcpu->exit.u.syndbg.recv_page = syndbg->control.recv_page; + hv_vcpu->exit.u.syndbg.pending_page = syndbg->control.pending_page; + vcpu->arch.complete_userspace_io = + kvm_hv_syndbg_complete_userspace; + + kvm_make_request(KVM_REQ_HV_EXIT, vcpu); +} + +static int syndbg_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data) +{ + struct kvm_hv_syndbg *syndbg = vcpu_to_hv_syndbg(vcpu); + int ret; + + trace_kvm_hv_syndbg_set_msr(vcpu->vcpu_id, + vcpu_to_hv_vcpu(vcpu)->vp_index, msr, data); + ret = 0; + switch (msr) { + case HV_X64_MSR_SYNDBG_CONTROL: + syndbg->control.control = data; + syndbg_exit(vcpu, msr); + break; + case HV_X64_MSR_SYNDBG_STATUS: + syndbg->control.status = data; + break; + case HV_X64_MSR_SYNDBG_SEND_BUFFER: + syndbg->control.send_page = data; + break; + case HV_X64_MSR_SYNDBG_RECV_BUFFER: + syndbg->control.recv_page = data; + break; + case HV_X64_MSR_SYNDBG_PENDING_BUFFER: + syndbg->control.pending_page = data; + syndbg_exit(vcpu, msr); + break; + case HV_X64_MSR_SYNDBG_OPTIONS: + syndbg->options = data; + break; + default: + ret = 1; + break; + } + + return ret; +} + +static int syndbg_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata) +{ + struct kvm_hv_syndbg *syndbg = vcpu_to_hv_syndbg(vcpu); + int ret; + + ret = 0; + switch (msr) { + case HV_X64_MSR_SYNDBG_CONTROL: + *pdata = syndbg->control.control; + break; + case HV_X64_MSR_SYNDBG_STATUS: + *pdata = syndbg->control.status; + break; + case HV_X64_MSR_SYNDBG_SEND_BUFFER: + *pdata = syndbg->control.send_page; + break; + case HV_X64_MSR_SYNDBG_RECV_BUFFER: + *pdata = syndbg->control.recv_page; + break; + case HV_X64_MSR_SYNDBG_PENDING_BUFFER: + *pdata = syndbg->control.pending_page; + break; + case HV_X64_MSR_SYNDBG_OPTIONS: + *pdata = syndbg->options; + break; + default: + ret = 1; + break; + } + + trace_kvm_hv_syndbg_get_msr(vcpu->vcpu_id, + vcpu_to_hv_vcpu(vcpu)->vp_index, msr, + *pdata); + return ret; +} + static int synic_get_msr(struct kvm_vcpu_hv_synic *synic, u32 msr, u64 *pdata, bool host) { @@ -800,6 +901,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr) case HV_X64_MSR_REENLIGHTENMENT_CONTROL: case HV_X64_MSR_TSC_EMULATION_CONTROL: case HV_X64_MSR_TSC_EMULATION_STATUS: + case HV_X64_MSR_SYNDBG_OPTIONS: + case HV_X64_MSR_SYNDBG_CONTROL ... HV_X64_MSR_SYNDBG_PENDING_BUFFER: r = true; break; } @@ -1061,6 +1164,9 @@ static int kvm_hv_set_msr_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data, if (!host) return 1; break; + case HV_X64_MSR_SYNDBG_OPTIONS: + case HV_X64_MSR_SYNDBG_CONTROL ... HV_X64_MSR_SYNDBG_PENDING_BUFFER: + return syndbg_set_msr(vcpu, msr, data); default: vcpu_unimpl(vcpu, "Hyper-V unhandled wrmsr: 0x%x data 0x%llx\n", msr, data); @@ -1227,6 +1333,9 @@ static int kvm_hv_get_msr_pw(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata) case HV_X64_MSR_TSC_EMULATION_STATUS: data = hv->hv_tsc_emulation_status; break; + case HV_X64_MSR_SYNDBG_OPTIONS: + case HV_X64_MSR_SYNDBG_CONTROL ... HV_X64_MSR_SYNDBG_PENDING_BUFFER: + return syndbg_get_msr(vcpu, msr, pdata); default: vcpu_unimpl(vcpu, "Hyper-V unhandled rdmsr: 0x%x\n", msr); return 1; @@ -1797,6 +1906,9 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid, { .function = HYPERV_CPUID_ENLIGHTMENT_INFO }, { .function = HYPERV_CPUID_IMPLEMENT_LIMITS }, { .function = HYPERV_CPUID_NESTED_FEATURES }, + { .function = HYPERV_CPUID_SYNDBG_VENDOR_AND_MAX_FUNCTIONS }, + { .function = HYPERV_CPUID_SYNDBG_INTERFACE }, + { .function = HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES }, }; int i, nent = ARRAY_SIZE(cpuid_entries); @@ -1821,7 +1933,7 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid, case HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS: memcpy(signature, "Linux KVM Hv", 12); - ent->eax = HYPERV_CPUID_NESTED_FEATURES; + ent->eax = HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES; ent->ebx = signature[0]; ent->ecx = signature[1]; ent->edx = signature[2]; @@ -1856,9 +1968,12 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid, ent->ebx |= HV_X64_POST_MESSAGES; ent->ebx |= HV_X64_SIGNAL_EVENTS; + ent->ebx |= HV_X64_DEBUGGING; ent->edx |= HV_FEATURE_FREQUENCY_MSRS_AVAILABLE; ent->edx |= HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE; + ent->edx |= HV_X64_GUEST_DEBUGGING_AVAILABLE; + ent->edx |= HV_FEATURE_DEBUG_MSRS_AVAILABLE; /* * Direct Synthetic timers only make sense with in-kernel @@ -1903,6 +2018,24 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid, break; + case HYPERV_CPUID_SYNDBG_VENDOR_AND_MAX_FUNCTIONS: + memcpy(signature, "Linux KVM Hv", 12); + + ent->eax = 0; + ent->ebx = signature[0]; + ent->ecx = signature[1]; + ent->edx = signature[2]; + break; + + case HYPERV_CPUID_SYNDBG_INTERFACE: + memcpy(signature, "VS#1\0\0\0\0\0\0\0\0", 12); + ent->eax = signature[0]; + break; + + case HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES: + ent->eax |= HV_X64_SYNDBG_CAP_ALLOW_KERNEL_DEBUGGING; + break; + default: break; } diff --git a/arch/x86/kvm/hyperv.h b/arch/x86/kvm/hyperv.h index 757cb578101c..6a86151fac53 100644 --- a/arch/x86/kvm/hyperv.h +++ b/arch/x86/kvm/hyperv.h @@ -46,6 +46,11 @@ static inline struct kvm_vcpu *synic_to_vcpu(struct kvm_vcpu_hv_synic *synic) return hv_vcpu_to_vcpu(container_of(synic, struct kvm_vcpu_hv, synic)); } +static inline struct kvm_hv_syndbg *vcpu_to_hv_syndbg(struct kvm_vcpu *vcpu) +{ + return &vcpu->kvm->arch.hyperv.hv_syndbg; +} + int kvm_hv_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data, bool host); int kvm_hv_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata, bool host); diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h index f194dd058470..bf6c3852868d 100644 --- a/arch/x86/kvm/trace.h +++ b/arch/x86/kvm/trace.h @@ -1515,6 +1515,57 @@ TRACE_EVENT(kvm_nested_vmenter_failed, __print_symbolic(__entry->err, VMX_VMENTER_INSTRUCTION_ERRORS)) ); +/* + * Tracepoint for syndbg_set_msr. + */ +TRACE_EVENT(kvm_hv_syndbg_set_msr, + TP_PROTO(int vcpu_id, u32 vp_index, u32 msr, u64 data), + TP_ARGS(vcpu_id, vp_index, msr, data), + + TP_STRUCT__entry( + __field(int, vcpu_id) + __field(u32, vp_index) + __field(u32, msr) + __field(u64, data) + ), + + TP_fast_assign( + __entry->vcpu_id = vcpu_id; + __entry->vp_index = vp_index; + __entry->msr = msr; + __entry->data = data; + ), + + TP_printk("vcpu_id %d vp_index %u msr 0x%x data 0x%llx", + __entry->vcpu_id, __entry->vp_index, __entry->msr, + __entry->data) +); + +/* + * Tracepoint for syndbg_get_msr. + */ +TRACE_EVENT(kvm_hv_syndbg_get_msr, + TP_PROTO(int vcpu_id, u32 vp_index, u32 msr, u64 data), + TP_ARGS(vcpu_id, vp_index, msr, data), + + TP_STRUCT__entry( + __field(int, vcpu_id) + __field(u32, vp_index) + __field(u32, msr) + __field(u64, data) + ), + + TP_fast_assign( + __entry->vcpu_id = vcpu_id; + __entry->vp_index = vp_index; + __entry->msr = msr; + __entry->data = data; + ), + + TP_printk("vcpu_id %d vp_index %u msr 0x%x data 0x%llx", + __entry->vcpu_id, __entry->vp_index, __entry->msr, + __entry->data) +); #endif /* _TRACE_KVM_H */ #undef TRACE_INCLUDE_PATH diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 5de200663f51..619c24bac79e 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1214,6 +1214,10 @@ static const u32 emulated_msrs_all[] = { HV_X64_MSR_VP_ASSIST_PAGE, HV_X64_MSR_REENLIGHTENMENT_CONTROL, HV_X64_MSR_TSC_EMULATION_CONTROL, HV_X64_MSR_TSC_EMULATION_STATUS, + HV_X64_MSR_SYNDBG_OPTIONS, + HV_X64_MSR_SYNDBG_CONTROL, HV_X64_MSR_SYNDBG_STATUS, + HV_X64_MSR_SYNDBG_SEND_BUFFER, HV_X64_MSR_SYNDBG_RECV_BUFFER, + HV_X64_MSR_SYNDBG_PENDING_BUFFER, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME, MSR_KVM_PV_EOI_EN, @@ -2906,6 +2910,8 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) */ break; case HV_X64_MSR_GUEST_OS_ID ... HV_X64_MSR_SINT15: + case HV_X64_MSR_SYNDBG_CONTROL ... HV_X64_MSR_SYNDBG_PENDING_BUFFER: + case HV_X64_MSR_SYNDBG_OPTIONS: case HV_X64_MSR_CRASH_P0 ... HV_X64_MSR_CRASH_P4: case HV_X64_MSR_CRASH_CTL: case HV_X64_MSR_STIMER0_CONFIG ... HV_X64_MSR_STIMER3_COUNT: @@ -3151,6 +3157,8 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) msr_info->data = 0x20000000; break; case HV_X64_MSR_GUEST_OS_ID ... HV_X64_MSR_SINT15: + case HV_X64_MSR_SYNDBG_CONTROL ... HV_X64_MSR_SYNDBG_PENDING_BUFFER: + case HV_X64_MSR_SYNDBG_OPTIONS: case HV_X64_MSR_CRASH_P0 ... HV_X64_MSR_CRASH_P4: case HV_X64_MSR_CRASH_CTL: case HV_X64_MSR_STIMER0_CONFIG ... HV_X64_MSR_STIMER3_COUNT: @@ -3323,6 +3331,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_HYPERV_TLBFLUSH: case KVM_CAP_HYPERV_SEND_IPI: case KVM_CAP_HYPERV_CPUID: + case KVM_CAP_HYPERV_DEBUGGING: case KVM_CAP_PCI_SEGMENT: case KVM_CAP_DEBUGREGS: case KVM_CAP_X86_ROBUST_SINGLESTEP: diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 7acfd6a2569a..cd813114d8ec 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -188,6 +188,7 @@ struct kvm_s390_cmma_log { struct kvm_hyperv_exit { #define KVM_EXIT_HYPERV_SYNIC 1 #define KVM_EXIT_HYPERV_HCALL 2 +#define KVM_EXIT_HYPERV_SYNDBG 3 __u32 type; __u32 pad; union { @@ -202,6 +203,14 @@ struct kvm_hyperv_exit { __u64 result; __u64 params[2]; } hcall; + struct { + __u32 msr; + __u64 control; + __u64 status; + __u64 send_page; + __u64 recv_page; + __u64 pending_page; + } syndbg; } u; }; @@ -1011,6 +1020,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_ARM_NISV_TO_USER 177 #define KVM_CAP_ARM_INJECT_EXT_DABT 178 #define KVM_CAP_S390_VCPU_RESETS 179 +#define KVM_CAP_HYPERV_DEBUGGING 180 #ifdef KVM_CAP_IRQ_ROUTING -- 2.24.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH v4 4/5] x86/kvm/hyper-v: enable hypercalls regardless of hypercall page 2020-03-09 18:20 [PATCH v4 0/5] x86/kvm/hyper-v: add support for synthetic debugger Jon Doron ` (2 preceding siblings ...) 2020-03-09 18:20 ` [PATCH v4 3/5] x86/kvm/hyper-v: Add support for synthetic debugger capability Jon Doron @ 2020-03-09 18:20 ` Jon Doron 2020-03-09 18:20 ` [PATCH v4 5/5] x86/kvm/hyper-v: Add support for synthetic debugger via hypercalls Jon Doron 4 siblings, 0 replies; 18+ messages in thread From: Jon Doron @ 2020-03-09 18:20 UTC (permalink / raw) To: kvm, linux-hyperv; +Cc: vkuznets, Jon Doron 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. Signed-off-by: Jon Doron <arilou@gmail.com> --- arch/x86/kvm/hyperv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index b6a97abe2bc9..917b10a637fc 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -1639,7 +1639,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 || + READ_ONCE(hv->hv_guest_os_id) != 0; } static void kvm_hv_hypercall_set_result(struct kvm_vcpu *vcpu, u64 result) -- 2.24.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH v4 5/5] x86/kvm/hyper-v: Add support for synthetic debugger via hypercalls 2020-03-09 18:20 [PATCH v4 0/5] x86/kvm/hyper-v: add support for synthetic debugger Jon Doron ` (3 preceding siblings ...) 2020-03-09 18:20 ` [PATCH v4 4/5] x86/kvm/hyper-v: enable hypercalls regardless of hypercall page Jon Doron @ 2020-03-09 18:20 ` Jon Doron 4 siblings, 0 replies; 18+ messages in thread From: Jon Doron @ 2020-03-09 18:20 UTC (permalink / raw) To: kvm, linux-hyperv; +Cc: vkuznets, Jon Doron There is another mode for the synthetic debugger which uses hypercalls to send/recv network data instead of the MSR interface. This interface is much slower and less recommended since you might get a lot of VMExits while KDVM polling for new packets to recv, rather than simply checking the pending page to see if there is data avialble and then request. Signed-off-by: Jon Doron <arilou@gmail.com> --- arch/x86/kvm/hyperv.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index 917b10a637fc..4a77ff61658b 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -1821,6 +1821,28 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu) } ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false); break; + case HVCALL_POST_DEBUG_DATA: + case HVCALL_RETRIEVE_DEBUG_DATA: + if (unlikely(fast)) { + ret = HV_STATUS_INVALID_PARAMETER; + break; + } + /* fallthrough */ + case HVCALL_RESET_DEBUG_SESSION: { + struct kvm_hv_syndbg *syndbg = vcpu_to_hv_syndbg(vcpu); + if (!(syndbg->options & HV_X64_SYNDBG_OPTION_USE_HCALLS)) { + ret = HV_STATUS_OPERATION_DENIED; + break; + } + vcpu->run->exit_reason = KVM_EXIT_HYPERV; + vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL; + vcpu->run->hyperv.u.hcall.input = param; + vcpu->run->hyperv.u.hcall.params[0] = ingpa; + vcpu->run->hyperv.u.hcall.params[1] = outgpa; + vcpu->arch.complete_userspace_io = + kvm_hv_hypercall_complete_userspace; + return 0; + } default: ret = HV_STATUS_INVALID_HYPERCALL_CODE; break; -- 2.24.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-03-12 19:34 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-09 18:20 [PATCH v4 0/5] x86/kvm/hyper-v: add support for synthetic debugger Jon Doron 2020-03-09 18:20 ` [PATCH v4 1/5] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit Jon Doron 2020-03-10 16:55 ` Vitaly Kuznetsov 2020-03-10 17:14 ` Jon Doron 2020-03-09 18:20 ` [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions Jon Doron 2020-03-09 21:00 ` Michael Kelley 2020-03-10 3:24 ` Jon Doron 2020-03-10 3:53 ` Michael Kelley 2020-03-10 4:28 ` Jon Doron 2020-03-10 14:23 ` Wei Liu 2020-03-12 13:51 ` Vitaly Kuznetsov 2020-03-12 14:59 ` Michael Kelley 2020-03-12 19:12 ` Jon Doron 2020-03-12 19:32 ` Michael Kelley 2020-03-12 19:34 ` Jon Doron 2020-03-09 18:20 ` [PATCH v4 3/5] x86/kvm/hyper-v: Add support for synthetic debugger capability Jon Doron 2020-03-09 18:20 ` [PATCH v4 4/5] x86/kvm/hyper-v: enable hypercalls regardless of hypercall page Jon Doron 2020-03-09 18:20 ` [PATCH v4 5/5] x86/kvm/hyper-v: Add support for synthetic debugger via hypercalls Jon Doron
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.