From patchwork Thu Sep 13 18:54:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jim Mattson X-Patchwork-Id: 10599985 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E3981112B for ; Thu, 13 Sep 2018 18:55:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D723D2B319 for ; Thu, 13 Sep 2018 18:55:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C9D4D2B324; Thu, 13 Sep 2018 18:55:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, USER_IN_DEF_DKIM_WL autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 699EA2B319 for ; Thu, 13 Sep 2018 18:55:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727992AbeINAFy (ORCPT ); Thu, 13 Sep 2018 20:05:54 -0400 Received: from mail-vk1-f201.google.com ([209.85.221.201]:55658 "EHLO mail-vk1-f201.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727231AbeINAFy (ORCPT ); Thu, 13 Sep 2018 20:05:54 -0400 Received: by mail-vk1-f201.google.com with SMTP id j80-v6so765583vke.22 for ; Thu, 13 Sep 2018 11:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=OLfyNBW9MXv5LWOof8cYJpLyIy/66cmLbkOPBN5ODwI=; b=jPoLFIRyLg3geKjDEFgHyC/M5zEjz/aiSQ+ps0aAANPF+qe6lEv+5F2LK+7cgyrq60 bblcIwc3jca+i0tZEi03bkqVbaqMRTQJUsjOzgb4pD0Qb9wXAfODVshN4p9nayyol2k4 FwlElxhWJsGep8WCAQntjVilt0RsBP/XIIiw2PIIdJbuydRoqy4aVnYMEv6qiLBPf7xd EnBCzE9jbU9sHBEbVCIRz0BMXEHjKN4/x41WG/cjU50i06/OEdDhZUnLkxJINlMDrT7h MtOmjeC/Aly2Y2jLIBerrzDFBBBnkgz0WzlwGh0K41NoxrmC8EJSChvuwI1fa1QrAE2I STvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=OLfyNBW9MXv5LWOof8cYJpLyIy/66cmLbkOPBN5ODwI=; b=WrykXYKxq15ay++IPdWm/d5oM1UVwo/beTEKE6oFJdox0VCCgRQI6ZgYJCqIWJOJ9K /67LCHwYbGIeYHSVZw36SGSQt33nzIPoUpI5lgPIIcnSMXweR8G9ZUEaJdzXBkDxHS8Z B6RVx9On5L8caBWmi3oh569T+zrATdpadXr02vb9qxMGx+hiOp+lkUFRTfM8qd0IAnE5 yncTMAXDCvE0QZf00CnahBD7qBj9CqET3AB7vMaXaprxmrKoPSmaNj8JGlGgLIMXSOiK m+ShvqEf7lLn0meGs8EdCmy0oaCz1h/zoup213qzUYRKYRbC4QjE66Ybp98j+3dnsVkR FXWA== X-Gm-Message-State: APzg51CuMZZAJrkcsUDF8FAD9YBNMHRMrFuF6hg9E7RysxtMke6R0+3Y OSCo5tiNXafC+yZ6/ZBltdA9t87P4qQFr4KfUVYy+WNBhelRa4mSLoFsFcyn2t0pOJzhmLUqqCT HS+KjgEM77RcaLYE3pzyzZgC934CnP1BzQ9JwlTYQ/ez9FgFpbI+vWEHR6J7xmO4= X-Google-Smtp-Source: ANB0VdZYTauSyw+6K3lY+cm3g2HNocRXxnshTy/rhtmBQkJ6Se3x//MXdeoXuZoRLAg8zwwx68723VujJZ9wSg== X-Received: by 2002:ab0:48d2:: with SMTP id y18-v6mr1894606uac.63.1536864907714; Thu, 13 Sep 2018 11:55:07 -0700 (PDT) Date: Thu, 13 Sep 2018 11:54:48 -0700 Message-Id: <20180913185448.106321-1-jmattson@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.19.0.rc2.392.g5ba43deb5a-goog Subject: [PATCH] KVM: nVMX: Always reflect #NM VM-exits to L1 From: Jim Mattson To: kvm@vger.kernel.org Cc: Abhiroop Dabral , Peter Shier , Jim Mattson Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When bit 3 (corresponding to CR0.TS) of the VMCS12 cr0_guest_host_mask field is clear, the VMCS12 guest_cr0 field does not necessarily hold the current value of the L2 CR0.TS bit, so the code that checked for L2's CR0.TS bit being set was incorrect. Moreover, I'm not sure that the CR0.TS check was adequate. (What if L2's CR0.EM was set, for instance?) Fortunately, lazy FPU has gone away, so L0 has lost all interest in intercepting #NM exceptions. See commit bd7e5b0899a4 ("KVM: x86: remove code for lazy FPU handling"). Therefore, there is no longer any question of which hypervisor gets first dibs. The #NM VM-exit should always be reflected to L1. (Note that the corresponding bit must be set in the VMCS12 exception_bitmap field for there to be an #NM VM-exit at all.) Fixes: ccf9844e5d99c ("kvm, vmx: Really fix lazy FPU on nested guest") Reported-by: Abhiroop Dabral Signed-off-by: Jim Mattson Reviewed-by: Peter Shier Tested-by: Abhiroop Dabral Reviewed-by: Liran Alon --- arch/x86/kvm/vmx.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 533a327372c8..49364b791eb9 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -1610,11 +1610,6 @@ static inline bool is_page_fault(u32 intr_info) return is_exception_n(intr_info, PF_VECTOR); } -static inline bool is_no_device(u32 intr_info) -{ - return is_exception_n(intr_info, NM_VECTOR); -} - static inline bool is_invalid_opcode(u32 intr_info) { return is_exception_n(intr_info, UD_VECTOR); @@ -9639,9 +9634,6 @@ static bool nested_vmx_exit_reflected(struct kvm_vcpu *vcpu, u32 exit_reason) return false; else if (is_page_fault(intr_info)) return !vmx->vcpu.arch.apf.host_apf_reason && enable_ept; - else if (is_no_device(intr_info) && - !(vmcs12->guest_cr0 & X86_CR0_TS)) - return false; else if (is_debug(intr_info) && vcpu->guest_debug & (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP))