On AMD hardware, Hyper-V doesn't work nested on KVM if L1 is started with
more than one vCPU. The problem is in NMI which is heavily used by Windows
on SMP systems.
This series fixes three related issues with the current NMI singlestep
logic and makes Windows with Hyper-V happy. The whole thing is far from
perfect, though, especially considering the interaction with user-mode
singlestepping (KVM_GUESTDBG_SINGLESTEP) which also uses the TRAP flag.
High-level, both KVM_GUESTDBG_SINGLESTEP and NMI window singlestep set
the TRAP flag to make the CPU exit after executing a single instruction.
But, in the absence of RFLAGS shadowing support in the hardware, for this
to work reliably KVM should make sure that this is 100% transparent to the
guest, i.e. the guest will never be able to tell that the TRAP flag is set.
NMI window singlestep kind of works with these patches because it's meant
only for short sequences (I believe that the original intention was to
step over an IRET but I doubt it's that simple anymore) so we can get
away with half-butting it. In particular, it's unlikely that the guest
would set the TRAP flag while the NMI window is closed. Properly handling
KVM_GUESTDBG_SINGLESTEP would likely involve intercepting PUSHF & POPF,
clearing the TRAP flag from the stack on interrupt entry, and possibly more.
Each of the following may be active, independently:
1) NMI injection looking for the window to open
2) User-mode singlestepping the guest using KVM_GUESTDBG_SINGLESTEP
3) The guest OS singlestepping a program
so an SVM_EXIT_EXCP_BASE + DB_VECTOR exit should be de-multiplexed to do
possibly several things: inject an NMI, notify user-mode, inject nested
exit or DB exception.
Ladi Prosek (4):
KVM: SVM: introduce disable_nmi_singlestep helper
KVM: nSVM: do not forward NMI window singlestep VM exits to L1
KVM: SVM: hide TF/RF flags used by NMI singlestep
KVM: SVM: don't NMI singlestep over event injection
