On 29/05/20 15:45, Jon Doron wrote: > 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. > > It's important to note that part of this feature has been subject to be > removed in future versions of Windows, which is why some of the > defintions will not be present the the TLFS but in the kvm hyperv header > instead. > > v12: > - Rebased on latest origin/master > - Make the KVM_CAP_HYPERV_SYNDBG always enabled, in previous version > userspace was required to explicitly enable the syndbg capability just > like with the EVMCS feature. I removed the capability altogether; the CPUID interface was added exactly to avoid a proliferation of capabilities. Otherwise it's great; queued, thanks. Paolo
