From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793661281; b=XQuFrHXkzy1srtr+HpyAId0i7d3UmLIAf28amJ6zC8BPQKnytJ2jRcaj4VUSIVDTshfD 1NaJnf44isiK3l9CVvthVDfi25aNBSAhuVI27ZGs7omlhB7ojJAEMmnxkDro+bvQPoGWE 5o8jDeM2FcLT23qFCFG9fgYVkBd/UQ9fyLcrjvl7QECTa4gfvuvonSdHfwR4fKAlnFqYr pjJGVSul0sEop1WdljkApjsCo8Jt0trH+r1z1Ivb1bWux0NggLaAXnYkD0QmJiyIlkp83 mf3/idviZIRQkZh44I2mOObOk33qg9zTL7qnIWdEty2Qmp6YtJfhbMoHA1Zl3BC+plA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793661281; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:Received:From:To:Cc:Subject:Date: Message-ID:In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:X-Scanned-By; bh=AVivRDqE/E1xFz1O6Qg3MBIK2Ylt3Q75h1TWUbJfbsY=; b=PxorXwCKJEpaltvJrhGFUx7jih1MYjTv11vm0l4qIrNO5tYI1L3xMBvU9t0Pz5tnaySI DhIw6ONuSEjzvKbDFxCFwy88Oz/FLD4K9KCvVvCIUzBmPvF9SSwQWzBQZB5hugCbosnl4 5i92Bh390rJHUwTSHVqfaK1B/EFUj/h0pLtIg9J9YAa6N7FZciaroYdFva62hkL5xJ7Sj 17VelkK7PaobTV6f4qsNS/I37rWkbVbfu6n7thGPWAwesg5GQ9ZVK7hHY9+CgmLpmTjwR l4zQgacjiunS0aIMI1vLwNsEjjfeZm8J6O0lvcH/3/AArjE2vNSy+eWFpyKH90d1l5Q== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Il4JjOUB; arc=none smtp.remote-ip=170.10.133.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA158606EE91 for ; Mon, 2 Nov 2026 23:14:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org CA158606EE91 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Il4JjOUB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1793661280; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AVivRDqE/E1xFz1O6Qg3MBIK2Ylt3Q75h1TWUbJfbsY=; b=Il4JjOUBW+8ao3tybYAPmVuogpdkmAqXk4eX5yo5wl3XBWQWUY74SKWEL3SNxodwXOtGac 3CM4tiG6WgZ6rca/Msml9FTdqKoVF2nv2sh0ywEdiHPsMPevUjrQCw5VzQw9v4GPy/Ri1n uwNWD79FLkLVx38twGTEHjPW8aHId00= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-O1977uQYPEqjU1seW4pJ2g-1; Mon, 02 Nov 2026 18:14:37 -0500 X-MC-Unique: O1977uQYPEqjU1seW4pJ2g-1 X-Mimecast-MFC-AGG-ID: O1977uQYPEqjU1seW4pJ2g_1793661276 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 337831800148; Mon, 2 Nov 2026 23:14:36 +0000 (UTC) Received: from virtlab1023.virt.eng.rdu2.dc.redhat.com (virtlab1023.virt.eng.rdu2.dc.redhat.com [10.18.48.26]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 3DACE26C; Mon, 2 Nov 2026 23:14:35 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Sean Christopherson , Stefan Teodorescu , Oren Yomtov , Chris Mason , stable@vger.kernel.org, Yosry Ahmed Subject: [PATCH 6/7] KVM: x86: Unconditionally reset MMU context when emulating INIT Date: Mon, 2 Nov 2026 18:14:27 -0500 Message-ID: <20261102231428.13523-7-pbonzini@redhat.com> In-Reply-To: <20261102231428.13523-1-pbonzini@redhat.com> References: <20261102231428.13523-1-pbonzini@redhat.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 From: Sean Christopherson Force an MMU reset when emulating an INIT even if paging was already disabled, as the MMU page role includes guest_mode (L2), i.e. an INIT while L2 is running with CR0.PG=0 will result in KVM running L1 with a stale MMU context. Alternatively, the reset could be scoped strictly to paging being enabled or L2 being active, but SMM is also encoded in the page role. Even though it _should_ be impossible for the vCPU to be INIT'd while SMM is active, there's zero value in not handling SMM. At that point, the only scenario where KVM _doesn't_ need to reset the MMU context is on an INIT with the vCPU running in Real Mode or Unpaged Protect Mode, and while INIT in those modes is somewhat common, it's far from a hot path and re-initializing the MMU is not expensive, especially when the role isn't changing (KVM elides most of the re-configuration in that case). Note, like the Fixes commit, this bug only affects nested SVM as INIT is an unconditional intercept on VMX, i.e. it's impossible to emulate INIT while L2 is active. Temporarily keep the guest TLB flush when CR0.PG is being cleared even though it is fully redundant with the flush that is emitted on all INIT events (KVM itself only does RESET when a vCPU is being created, i.e. when CR0.PG must be '0'). Fixes: ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") Reported-by: Stefan Teodorescu Reported-by: Oren Yomtov Reported-by: Chris Mason Cc: stable@vger.kernel.org Cc: Yosry Ahmed Signed-off-by: Sean Christopherson Message-ID: <20261022015407.279870-2-seanjc@google.com> Signed-off-by: Paolo Bonzini --- arch/x86/kvm/x86.c | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c4a06214cde6..09c6df00ebb6 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9731,18 +9731,23 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) kvm_x86_call(set_efer)(vcpu, 0); kvm_x86_call(update_exception_bitmap)(vcpu); - /* - * On the standard CR0/CR4/EFER modification paths, there are several - * complex conditions determining whether the MMU has to be reset and/or - * which PCIDs have to be flushed. However, CR0.WP and the paging-related - * bits in CR4 and EFER are irrelevant if CR0.PG was '0'; and a reset+flush - * is needed anyway if CR0.PG was '1' (which can only happen for INIT, as - * CR0 will be '0' prior to RESET). So we only need to check CR0.PG here. - */ - if (old_cr0 & X86_CR0_PG) { + if (old_cr0 & X86_CR0_PG) kvm_make_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu); - kvm_mmu_reset_context(vcpu); - } + + /* + * Unconditionally reset the MMU, even though super strictly speaking, + * a MMU reset is only necessary if and only one of the page role bits + * is changing. All of the CR0/CR4/EFER bits effectively get covered + * by checking CR0.PG=1, as CR0.WP and the paging-related bits in CR4 + * and EFER are irrelevant if CR0.PG was '0'. Subtly, if the vCPU was + * in guest mode (L2) or SMM (although emulating INIT in SMM _should_ + * be impossible), an MMU reset is also necessary as "guest mode" and + * "smm" are both encoded in the shadow page role. As a result, the + * only scenarios where an MMU reset is *not* needed is if the vCPU is + * in Real Mode or Unpaged Protected Mode, and micro-optimizing those + * paths are not worth the risk of running with a stale MMU context. + */ + kvm_mmu_reset_context(vcpu); /* * Intel's SDM states that all TLB entries are flushed on INIT. AMD's -- 2.52.0