From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22FD0C433FE for ; Fri, 29 Apr 2022 17:36:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236374AbiD2Rjp (ORCPT ); Fri, 29 Apr 2022 13:39:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379725AbiD2Riv (ORCPT ); Fri, 29 Apr 2022 13:38:51 -0400 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D5E2218E21 for ; Fri, 29 Apr 2022 10:35:32 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id i24so7487824pfa.7 for ; Fri, 29 Apr 2022 10:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=A2o+Ws1INtn1MzI5In4+SjIaL3aTcpeQBl4+z8iQMc4=; b=NYOSSTKbRD04TVB73Y0G8dVDDfWwHH/CPTSC7daECEsRY/h46kd7k6dLGhMDlrO1s0 JvVKQn0GcojLy5mGg40A8qxM6FQZIPQi4E3s2mKqKKJv1jzvkw7Se89NURix2hwEHt+H MtTv2gISdz6cnht5Tg5kg6rrV6Fx/cSjRSn7pGTnc+7EPv9mPozYNWHGWwqgp2tXR2J9 AGd9rij6dqLuXxB/ysKy16JHfzxL4TVnj0tTvZO4vvsqiepcOV1fqKW5w7XrakLIZ828 TsckfsDGxa6bcewapYWOT2P0Nj7VjF3Hf6IbOd47FClYM0iOw0IF590tdnx7A93nrUyb RxZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=A2o+Ws1INtn1MzI5In4+SjIaL3aTcpeQBl4+z8iQMc4=; b=vZKTCIHAhCELcU9Dz9HVZywqB3bZcsgyWl8ZLZeOuArFyxVFUFiu7dzf+jljdo6T5Z eC70aTWFaR6TcQWz6kRbYXc85+f6ZduPLcrZBE6PULZ+zTaXPOtgiqIb8QIMBAkpmQVB vjmFOg1DWOOQWzjytcIvzPVIUtp1ZikGXGGgqbn8D36yrVXUAS8fhPUNGyGaBoe6j3Pl IFWC8ZLsq7x2X6uufincW4QFKCOOpo+KwO3A+zg8HqKBjKmY1Ve1rjWOctLZl9dHbkqO JbKRx7ZWIWS7Yod12amG4MX6w3mAXpKw4EJt3yoKU+5Vtpofg1DK+jd0UW7IBu62vmUm H1xA== X-Gm-Message-State: AOAM533p0FOIBR647/WkPHQny7XrkC12lD9EUXusfxOAZIzEHKJkA3xH HP+HO1mk246ZB3Lz6Mq4L+aUwG9kw5BXTA== X-Google-Smtp-Source: ABdhPJySHzOFet3agObDF17Dhwfya9aBtbqQNVx7EZSgv30DDlpfHWNXSSP+dep1o8EZziq4Eyq0uA== X-Received: by 2002:a63:1c1d:0:b0:39d:9a7c:593b with SMTP id c29-20020a631c1d000000b0039d9a7c593bmr367462pgc.157.1651253732177; Fri, 29 Apr 2022 10:35:32 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id y38-20020a056a001ca600b0050dafe16d7bsm2804025pfw.26.2022.04.29.10.35.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Apr 2022 10:35:31 -0700 (PDT) Date: Fri, 29 Apr 2022 17:35:28 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, mlevitsk@redhat.com, stable@vger.kernel.org Subject: Re: [PATCH 1/3] KVM: x86: make vendor code check for all nested events Message-ID: References: <20220427173758.517087-1-pbonzini@redhat.com> <20220427173758.517087-2-pbonzini@redhat.com> <0b554e22-6766-8299-287c-c40240c08536@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0b554e22-6766-8299-287c-c40240c08536@redhat.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Apr 29, 2022, Paolo Bonzini wrote: > On 4/29/22 19:03, Sean Christopherson wrote: > > This doesn't even compile... > > > > arch/x86/kvm/vmx/nested.c: In function ‘vmx_has_nested_events’: > > arch/x86/kvm/vmx/nested.c:3862:61: error: ‘vmx’ undeclared (first use in this function) > > 3862 | return nested_vmx_preemption_timer_pending(vcpu) || vmx->nested.mtf_pending; > > | ^~~ > > arch/x86/kvm/vmx/nested.c:3862:61: note: each undeclared identifier is reported only once for each function it appears in > > CC [M] arch/x86/kvm/svm/svm_onhyperv.o > > arch/x86/kvm/vmx/nested.c:3863:1: error: control reaches end of non-void function [-Werror=return-type] > > 3863 | } > > | ^ > > cc1: all warnings being treated as errors > > LD [M] arch/x86/kvm/kvm.o > > Yeah, it doesn't. Of course this will need a v2, also because there are > failures in the vmx tests. Heh, I suspected there would be failures, I was about to type up a response to patch 3. MTF is subtly relying on the call from kvm_vcpu_running() to inject the event. From: Sean Christopherson Date: Fri, 29 Apr 2022 17:30:54 +0000 Subject: [PATCH] KVM: nVMX: Make an event request when pending an MTF nested VM-Exit Set KVM_REQ_EVENT when MTF becomes pending to ensure that KVM will run through inject_pending_event() and thus vmx_check_nested_events() prior to re-entering the guest. MTF currently works by virtue of KVM's hack that calls kvm_check_nested_events() from kvm_vcpu_running(), but that hack will be removed in the near future. Fixes: 5ef8acbdd687 ("KVM: nVMX: Emulate MTF when performing instruction emulation") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/vmx.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index d58b763df855..4c635bc08105 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -1577,10 +1577,12 @@ static void vmx_update_emulated_instruction(struct kvm_vcpu *vcpu) */ if (nested_cpu_has_mtf(vmcs12) && (!vcpu->arch.exception.pending || - vcpu->arch.exception.nr == DB_VECTOR)) + vcpu->arch.exception.nr == DB_VECTOR)) { vmx->nested.mtf_pending = true; - else + kvm_make_request(KVM_REQ_EVENT, vcpu); + } else { vmx->nested.mtf_pending = false; + } } static int vmx_skip_emulated_instruction(struct kvm_vcpu *vcpu) base-commit: 39aa5903e8c407e5128c15aeabb0717b275b007e --