On 10/03/2020, Michael Kelley wrote:
From: Jon Doron <arilou@xxxxxxxxx> Sent: Monday, March 9, 2020 8:25 PM
On 09/03/2020, Michael Kelley wrote:
>From: Jon Doron <arilou@xxxxxxxxx> 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@xxxxxxxxx>
>
>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.
