Received: by 10.223.176.46 with SMTP id f43csp1907930wra; Thu, 25 Jan 2018 01:51:33 -0800 (PST) X-Google-Smtp-Source: AH8x224ETYiSq1oAFwZ/P0EHUJS6mgqwFS+rZCFIWRYQXWwZXYf65gDmCkRObS4qNMEcdnwOd6aQ X-Received: by 10.101.76.193 with SMTP id n1mr12177278pgt.194.1516873893047; Thu, 25 Jan 2018 01:51:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516873893; cv=none; d=google.com; s=arc-20160816; b=ruorlNbuFqqUvwzcYAOmRLE9MfyhxQQh7tQEj6yPJuqzW9hOhXWXgM4qaFGuRT20by sCjvSoRxzX945dDtDFxavLq418syGzy6PzUjEBhUHTk1Uat2QqvsIlulrz5J1xRbEHdI ordL+IQRRlHxwQfkIINStTzJVrRWbnVByJ1mmw17v2QfeH7TStIkzPocBEyOGYztKbku HOKVfxdBbIRgfUQRENAIhpspMq1TwBc3mzyYs6sAUvI2oxO1eSi3gFiazqgT1jxbproB O8h3dY1WkgGF+J6Vp78NRWTs3mnMc8LgOLh6QajZM025drawtVLkwJ5KJTfbdfW1LBFr QtjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=67bvsrAIcJD+2TEfnphLN1//kAx82xRijg53Vp2pIKI=; b=yz3XvKMrgosdzi1awhVEhOxzX5uwmBdnSUoU8+i4fi4RBzas1t6qDBY9u8xYbYeTJI IEsMTepGIb7MSPAO+jISz4JlW+AaUJ/QO9frjfAisEcgQ18cV/NpdHjKoevRWDZbw0Bl vBRjrvVlnJfZoLOIo83eVD5w7JBKBiXSOQ9ImWS25iw+N2RKfRm5zzqXr2RNU/ilYIx/ IkcYUEheSwu7PU5B7GiB3OcAmxnqU9OJT6nSt/34NY4VFsP4EevsZ2zJzfhzepcpo6S7 u/e6KFzjY/S75cp21BM4G5MoZNjfZDDuKKqZk9j9cBhLqjX8uLOKWRtndjDqAcEw8mxd SIuA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e12-v6si751808plj.600.2018.01.25.01.51.19; Thu, 25 Jan 2018 01:51: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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751475AbeAYJuX (ORCPT + 99 others); Thu, 25 Jan 2018 04:50:23 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:44376 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750769AbeAYJuV (ORCPT ); Thu, 25 Jan 2018 04:50:21 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 6FA01CC7; Thu, 25 Jan 2018 09:50:20 +0000 (UTC) Date: Thu, 25 Jan 2018 10:50:19 +0100 From: Greg KH To: Liran Alon Cc: Alexander.Levin@microsoft.com, konrad.wilk@oracle.com, stable@vger.kernel.org, rkrcmar@redhat.com, pbonzini@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH AUTOSEL for 4.14 006/100] KVM: nVMX/nSVM: Don't intercept #UD when running L2 Message-ID: <20180125095019.GB30255@kroah.com> References: <4693d8ab-1c86-44b6-b24f-009ee8766c1e@default> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4693d8ab-1c86-44b6-b24f-009ee8766c1e@default> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 25, 2018 at 01:25:18AM -0800, Liran Alon wrote: > > ----- Alexander.Levin@microsoft.com wrote: > > > From: Liran Alon > > > > [ Upstream commit ac9b305caa0df6f5b75d294e4b86c1027648991e ] > > > > When running L2, #UD should be intercepted by L1 or just forwarded > > directly to L2. It should not reach L0 x86 emulator. > > Therefore, set intercept for #UD only based on L1 exception-bitmap. > > > > Also add WARN_ON_ONCE() on L0 #UD intercept handlers to make sure > > it is never reached while running L2. > > > > This improves commit ae1f57670703 ("KVM: nVMX: Do not emulate #UD > > while > > in guest mode") by removing an unnecessary exit from L2 to L0 on #UD > > when L1 doesn't intercept it. > > > > In addition, SVM L0 #UD intercept handler doesn't handle correctly > > the > > case it is raised from L2. In this case, it should forward the #UD to > > guest instead of x86 emulator. As done in VMX #UD intercept handler. > > This commit fixes this issue as-well. > > > > Signed-off-by: Liran Alon > > Reviewed-by: Nikita Leshenko > > Reviewed-by: Konrad Rzeszutek Wilk > > Signed-off-by: Konrad Rzeszutek Wilk > > Reviewed-by: Paolo Bonzini > > Reviewed-by: Wanpeng Li > > Signed-off-by: Radim Krčmář > > Signed-off-by: Sasha Levin > > --- > > arch/x86/kvm/svm.c | 9 ++++++++- > > arch/x86/kvm/vmx.c | 9 ++++----- > > 2 files changed, 12 insertions(+), 6 deletions(-) > > > > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > > index 6a8284f72328..c8be4e6d365b 100644 > > --- a/arch/x86/kvm/svm.c > > +++ b/arch/x86/kvm/svm.c > > @@ -362,6 +362,7 @@ static void recalc_intercepts(struct vcpu_svm > > *svm) > > { > > struct vmcb_control_area *c, *h; > > struct nested_state *g; > > + u32 h_intercept_exceptions; > > > > mark_dirty(svm->vmcb, VMCB_INTERCEPTS); > > > > @@ -372,9 +373,14 @@ static void recalc_intercepts(struct vcpu_svm > > *svm) > > h = &svm->nested.hsave->control; > > g = &svm->nested; > > > > + /* No need to intercept #UD if L1 doesn't intercept it */ > > + h_intercept_exceptions = > > + h->intercept_exceptions & ~(1U << UD_VECTOR); > > + > > c->intercept_cr = h->intercept_cr | g->intercept_cr; > > c->intercept_dr = h->intercept_dr | g->intercept_dr; > > - c->intercept_exceptions = h->intercept_exceptions | > > g->intercept_exceptions; > > + c->intercept_exceptions = > > + h_intercept_exceptions | g->intercept_exceptions; > > c->intercept = h->intercept | g->intercept; > > } > > > > @@ -2189,6 +2195,7 @@ static int ud_interception(struct vcpu_svm > > *svm) > > { > > int er; > > > > + WARN_ON_ONCE(is_guest_mode(&svm->vcpu)); > > er = emulate_instruction(&svm->vcpu, EMULTYPE_TRAP_UD); > > if (er == EMULATE_USER_EXIT) > > return 0; > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > > index ef16cf0f7cfd..36628ed362d8 100644 > > --- a/arch/x86/kvm/vmx.c > > +++ b/arch/x86/kvm/vmx.c > > @@ -1891,7 +1891,7 @@ static void update_exception_bitmap(struct > > kvm_vcpu *vcpu) > > { > > u32 eb; > > > > - eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) | > > + eb = (1u << PF_VECTOR) | (1u << MC_VECTOR) | > > (1u << DB_VECTOR) | (1u << AC_VECTOR); > > if ((vcpu->guest_debug & > > (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) == > > @@ -1909,6 +1909,8 @@ static void update_exception_bitmap(struct > > kvm_vcpu *vcpu) > > */ > > if (is_guest_mode(vcpu)) > > eb |= get_vmcs12(vcpu)->exception_bitmap; > > + else > > + eb |= 1u << UD_VECTOR; > > > > vmcs_write32(EXCEPTION_BITMAP, eb); > > } > > @@ -5919,10 +5921,7 @@ static int handle_exception(struct kvm_vcpu > > *vcpu) > > return 1; /* already handled by vmx_vcpu_run() */ > > > > if (is_invalid_opcode(intr_info)) { > > - if (is_guest_mode(vcpu)) { > > - kvm_queue_exception(vcpu, UD_VECTOR); > > - return 1; > > - } > > + WARN_ON_ONCE(is_guest_mode(vcpu)); > > er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD); > > if (er == EMULATE_USER_EXIT) > > return 0; > > -- > > 2.11.0 > > Just wanted stable maintainers to note that Jim, Paolo & myself decided eventually to revert this commit along with commit ae1f57670703 on upstream KVM. However, it is true that this commit makes commit ae1f57670703 more complete. Therefore we have 2 options here: > 1) Apply this backport and sometime in the future also apply the reverts of both these commits with Paolo's commit which reverts them. Being "bug compatible" is good, I like that option :) When is the revert patch going to hit Linus's tree? During the 4.16-rc1 merge window? thanks, greg k-h