Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1375995ybf; Thu, 27 Feb 2020 09:46:33 -0800 (PST) X-Google-Smtp-Source: APXvYqwe8e9vlL8ICsPAl6e2HGwJ5rV1idswxs9QyqkAW26VgRzdomj5/kWMfpME8LZnEiJX5x14 X-Received: by 2002:aca:cf12:: with SMTP id f18mr131831oig.81.1582825593528; Thu, 27 Feb 2020 09:46:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582825593; cv=none; d=google.com; s=arc-20160816; b=SsOjdgT5mr2yCJNP9iAkP0cbZoRLzuQvUXl4bR5pfmHf6gBaqs83aFZ4Y0KeBJ/DS/ VfhQu595oYjRorEtRMtmppP0l5gR1n8zE10EeChtrdLTjD1dDFa5jD/n2MWtxV5Y5T21 C2ib1rZb5aI39NOT4535rT4VY+osPWtDQ1aXOB1INAn/RUJYH2BHEaayOeW3rkE2sGpH ChRqJUpXU2DkkG1H2TyX7J0DYK3r6FitmP6MHyVSRS4pvm/yM6bqQlVhmnkavZqPJ9Rn 1c1Jg1LIRhBzt6Ig7JPyNI56DjVbIg4goStbMBqM67s2la41cj7apoQw6NzP0zSxosMP mj4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=G1B8/z06NMu2dcOg4p9iVDK6t2S3SIGab2Di9Avdghg=; b=nxP65Sgb0UROJTYsFixKQFE3r0N+wPwraDRZMKe80Ft3Bw8gaVtNYEgyiOZL8bFjcn QbCvDEsyq9P1SoZ/ZFZnDyeEoXgSUaEurbwMkASuEa/Yc/UEg7iCVijWjKrm2PbPo7qs WQnhwtEdM6mt8R9Swlgsoq2NlruGYQpgxZT8zsxI3IUrFVSwErvAtx1cuiJbw3gmVXN6 5X18DWSCMM1WPJFCX4vJPu23lCDVXDJ1HrHcTEa1FGvT29PvsAGU6YpFb2OEysGuauc6 7wxxfWgNYuIbs4mNY8hWjWPnYqLkOTqLNY3SI6vG11y9Ncy93QcZTk29y3Nn45luDOoA 802g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 194si264862oii.2.2020.02.27.09.46.20; Thu, 27 Feb 2020 09:46:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730792AbgB0RpA (ORCPT + 99 others); Thu, 27 Feb 2020 12:45:00 -0500 Received: from mga06.intel.com ([134.134.136.31]:18526 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730669AbgB0Rok (ORCPT ); Thu, 27 Feb 2020 12:44:40 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 09:44:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,492,1574150400"; d="scan'208";a="317859094" Received: from sjchrist-coffee.jf.intel.com ([10.54.74.202]) by orsmga001.jf.intel.com with ESMTP; 27 Feb 2020 09:44:38 -0800 From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Xiaoyao Li Subject: [PATCH] KVM: nVMX: Consult only the "basic" exit reason when routing nested exit Date: Thu, 27 Feb 2020 09:44:30 -0800 Message-Id: <20200227174430.26371-1-sean.j.christopherson@intel.com> X-Mailer: git-send-email 2.24.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Consult only the basic exit reason, i.e. bits 15:0 of vmcs.EXIT_REASON, when determining whether a nested VM-Exit should be reflected into L1 or handled by KVM in L0. For better or worse, the switch statement in nested_vmx_exit_reflected() currently defaults to "true", i.e. reflects any nested VM-Exit without dedicated logic. Because the case statements only contain the basic exit reason, any VM-Exit with modifier bits set will be reflected to L1, even if KVM intended to handle it in L0. Practically speaking, this only affects EXIT_REASON_MCE_DURING_VMENTRY, i.e. a #MC that occurs on nested VM-Enter would be incorrectly routed to L1, as "failed VM-Entry" is the only modifier that KVM can currently encounter. The SMM modifiers will never be generated as KVM doesn't support/employ a SMI Transfer Monitor. Ditto for "exit from enclave", as KVM doesn't yet support virtualizing SGX, i.e. it's impossible to enter an enclave in a KVM guest (L1 or L2). Fixes: 644d711aa0e1 ("KVM: nVMX: Deciding if L0 or L1 should handle an L2 exit") Cc: Jim Mattson Cc: Xiaoyao Li Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/nested.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 0946122a8d3b..127065bbde2c 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -5554,7 +5554,7 @@ bool nested_vmx_exit_reflected(struct kvm_vcpu *vcpu, u32 exit_reason) vmcs_read32(VM_EXIT_INTR_ERROR_CODE), KVM_ISA_VMX); - switch (exit_reason) { + switch ((u16)exit_reason) { case EXIT_REASON_EXCEPTION_NMI: if (is_nmi(intr_info)) return false; -- 2.24.1