Re: [PATCH v4 2/5] x86/hyper-v: Add synthetic debugger definitions

[Jon Doron <arilou@gmail.com>]

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.