From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ladi Prosek Subject: [PATCH 0/4] KVM: SVM: improve NMI window singlestep Date: Thu, 15 Jun 2017 13:20:28 +0200 Message-ID: <20170615112032.15812-1-lprosek@redhat.com> Cc: rkrcmar@redhat.com To: kvm@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34282 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751623AbdFOLUh (ORCPT ); Thu, 15 Jun 2017 07:20:37 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 48E2080F97 for ; Thu, 15 Jun 2017 11:20:37 +0000 (UTC) Sender: kvm-owner@vger.kernel.org List-ID: 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