From nobody Tue Apr 7 06:49:37 2026 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 9CD30ECAAD4 for ; Tue, 30 Aug 2022 23:18:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232101AbiH3XSy (ORCPT ); Tue, 30 Aug 2022 19:18:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231873AbiH3XSH (ORCPT ); Tue, 30 Aug 2022 19:18:07 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 969B8A263F for ; Tue, 30 Aug 2022 16:16:45 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id l9-20020a252509000000b00695eb4f1422so857222ybl.13 for ; Tue, 30 Aug 2022 16:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc; bh=deckfdT/A/DPIznZY3aZvebzVPMaF1XxbtwHCNkJXFI=; b=Bue2rck+1YunO2USXcMoE1HA228yX08f9TqadNQEE+1XGV/0FP+x7Gu2Zo8TpSgiz4 q+DdM/KnrnqLdr1/zmpW9ECG/C4QTM8BAqtQUnd4rQ2Qlz+c+l7gsF9ZSQYEjlc57WdK LcT+eY92SK6L/Uw3+4no8UqI99ijE5F8OqW6mnnT/SVsrd+2FglDkg+FPnYM0DKxjhh5 oTZWMVgowRj6+bpMLu4+5t7KIIc/GstlnIHbGMafa6XSX/ECrjnBDBiLXfR4hKjdK5K3 gJGUaDGLCAbtXUXqTmhMB2sXWhdswVkcqKGDegMBndHQMx0SQhDFkvdN3UAeB+iK/CaA C6EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc; bh=deckfdT/A/DPIznZY3aZvebzVPMaF1XxbtwHCNkJXFI=; b=zUV+8g7kCPBaCIEyFBQcu6aRlXaMVJ0mB69Znj5zz2WnVhzJBjSHDlbvr4+e9AAi8H 3/mYcZegfMXBX4KOL7oDpnoLO3PW0ubhAQIesLXul7wDGY2uGWurHXSJQlQpe0qlFVXg 3KWj8qHvNBFs2hwmZ8xVS7U72A7U6pt6iuRGAz28fO2Hnpmg2Oq0XPtdPX+vrBsWm2u7 LK2K3YLzLJM44JEjtxrK39gs1qfqsrWrFh5jq14x0pSRddyncqaepPse7IqvoGAwz9T2 dHg2o3s+0CtzYE83JqIGn7QerXy3p0QvrBjHMt1TqlTd0CNOU2J7cKan7ENaWHvV14T3 Zo5w== X-Gm-Message-State: ACgBeo2zznof2TkQlyz8S2jSNeCbCrANnaJkUh8JkQ80AMIg8D9b1WSl 2SgBJatUcgBR7oQ5rFh30DJcvsT3eus= X-Google-Smtp-Source: AA6agR5PKKNgKEUCmv1CKdtSY4LvtPgGItctt3djDy6IoIEgN8l1lxsBwv9cqAVr5TR0V47Jd6tKWHdRgEY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:100b:b0:695:bd4e:95d6 with SMTP id w11-20020a056902100b00b00695bd4e95d6mr13920950ybt.595.1661901395593; Tue, 30 Aug 2022 16:16:35 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 30 Aug 2022 23:15:58 +0000 In-Reply-To: <20220830231614.3580124-1-seanjc@google.com> Mime-Version: 1.0 References: <20220830231614.3580124-1-seanjc@google.com> X-Mailer: git-send-email 2.37.2.672.g94769d06f0-goog Message-ID: <20220830231614.3580124-12-seanjc@google.com> Subject: [PATCH v5 11/27] KVM: nVMX: Unconditionally clear mtf_pending on nested VM-Exit From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson , Maxim Levitsky , Oliver Upton , Peter Shier Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Clear mtf_pending on nested VM-Exit instead of handling the clear on a case-by-case basis in vmx_check_nested_events(). The pending MTF should never survive nested VM-Exit, as it is a property of KVM's run of the current L2, i.e. should never affect the next L2 run by L1. In practice, this is likely a nop as getting to L1 with nested_run_pending is impossible, and KVM doesn't correctly handle morphing a pending exception that occurs on a prior injected exception (need for re-injected exception being the other case where MTF isn't cleared). However, KVM will hopefully soon correctly deal with a pending exception on top of an injected exception. Add a TODO to document that KVM has an inversion priority bug between SMIs and MTF (and trap-like #DBS), and that KVM also doesn't properly save/restore MTF across SMI/RSM. Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- arch/x86/kvm/vmx/nested.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index d11c785b2c1c..51005fef0148 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -3905,16 +3905,8 @@ static int vmx_check_nested_events(struct kvm_vcpu *= vcpu) unsigned long exit_qual; bool block_nested_events =3D vmx->nested.nested_run_pending || kvm_event_needs_reinjection(vcpu); - bool mtf_pending =3D vmx->nested.mtf_pending; struct kvm_lapic *apic =3D vcpu->arch.apic; =20 - /* - * Clear the MTF state. If a higher priority VM-exit is delivered first, - * this state is discarded. - */ - if (!block_nested_events) - vmx->nested.mtf_pending =3D false; - if (lapic_in_kernel(vcpu) && test_bit(KVM_APIC_INIT, &apic->pending_events)) { if (block_nested_events) @@ -3923,6 +3915,9 @@ static int vmx_check_nested_events(struct kvm_vcpu *v= cpu) clear_bit(KVM_APIC_INIT, &apic->pending_events); if (vcpu->arch.mp_state !=3D KVM_MP_STATE_INIT_RECEIVED) nested_vmx_vmexit(vcpu, EXIT_REASON_INIT_SIGNAL, 0, 0); + + /* MTF is discarded if the vCPU is in WFS. */ + vmx->nested.mtf_pending =3D false; return 0; } =20 @@ -3945,6 +3940,11 @@ static int vmx_check_nested_events(struct kvm_vcpu *= vcpu) * fault-like exceptions, TSS T flag #DB (not emulated by KVM, but * could theoretically come in from userspace), and ICEBP (INT1). * + * TODO: SMIs have higher priority than MTF and trap-like #DBs (except + * for TSS T flag #DBs). KVM also doesn't save/restore pending MTF + * across SMI/RSM as it should; that needs to be addressed in order to + * prioritize SMI over MTF and trap-like #DBs. + * * Note that only a pending nested run can block a pending exception. * Otherwise an injected NMI/interrupt should either be * lost or delivered to the nested hypervisor in the IDT_VECTORING_INFO, @@ -3960,7 +3960,7 @@ static int vmx_check_nested_events(struct kvm_vcpu *v= cpu) return 0; } =20 - if (mtf_pending) { + if (vmx->nested.mtf_pending) { if (block_nested_events) return -EBUSY; nested_vmx_update_pending_dbg(vcpu); @@ -4557,6 +4557,9 @@ void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 vm_= exit_reason, struct vcpu_vmx *vmx =3D to_vmx(vcpu); struct vmcs12 *vmcs12 =3D get_vmcs12(vcpu); =20 + /* Pending MTF traps are discarded on VM-Exit. */ + vmx->nested.mtf_pending =3D false; + /* trying to cancel vmlaunch/vmresume is a bug */ WARN_ON_ONCE(vmx->nested.nested_run_pending); =20 --=20 2.37.2.672.g94769d06f0-goog