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 (undocumented so it's not going to the hyperv-tlfs.h) 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. The first mode implementation is to simply exit to user-space when either the control MSR or the pending MSR are 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 Documentation/virt/kvm/api.rst | 18 ++++ arch/x86/include/asm/hyperv-tlfs.h | 6 ++ arch/x86/include/asm/kvm_host.h | 13 +++ arch/x86/kvm/hyperv.c | 162 ++++++++++++++++++++++++++++- arch/x86/kvm/hyperv.h | 27 +++++ arch/x86/kvm/trace.h | 51 +++++++++ arch/x86/kvm/x86.c | 9 ++ include/uapi/linux/kvm.h | 13 +++ 8 files changed, 297 insertions(+), 2 deletions(-) -- 2.24.1
