From nobody Mon Jun 8 18:57:24 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B8D463D412A for ; Wed, 27 May 2026 12:06:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883569; cv=none; b=Tizc77+9y84I6bMvEujNZ5rtR5AkmguDfNKYZu5bbv8KqYNLZC9WxmaE70LyI90O1ThTL64vUJaqKssQYX4n3FBmNbdxdt65fy1LyR+A9EvXxSD+MTYTh54NJXn5Cp7CZDEkIeNAatGNoYaNgrG6h30zjqKTqLeXh00Dz9bICmA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883569; c=relaxed/simple; bh=0auwx32uSZnkYKaPRx8GNEzMiA4MgEnQ5JpHWMraEKY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YGWpT7smpnOmLZ0bOGOvxOapO8e890PWpBh99Oum43DVA61m9svqVbLcN6rOxBqeirGT53XHFzzyWXTANPlluPZq7GvsGxaPnYU4FXZckSqRnk3JApfWZagijnnF65tY021b2Czbfiel2Y3s8N8EUkUfKeILAhqP0Qc+/uY/dnM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BZVP8+RI; arc=none smtp.client-ip=170.10.133.124 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) header.d=redhat.com header.i=@redhat.com header.b="BZVP8+RI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779883566; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PgYdfeXM9CLAuTMEeSJ9fjZzABhDnraN4XOttb9xDNA=; b=BZVP8+RI14BKqvMcWmU4ng4FB102jUXjJUKDkJj6EuLLSa8OuHZvhT4VW01ZlUmx+fM6mQ 3viVsnQ5oQ91sMbwmvypb9qd9djFdkBpK/Bafn5FTWK8OvJU3bvkgeHP8oHeTJd2q8nAD5 rgaMKw2UsKkoordqHOxx6ibdOFx0ZJ0= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-302-6rjxowhiNROn7G8B2T5oXg-1; Wed, 27 May 2026 08:06:03 -0400 X-MC-Unique: 6rjxowhiNROn7G8B2T5oXg-1 X-Mimecast-MFC-AGG-ID: 6rjxowhiNROn7G8B2T5oXg_1779883562 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2EC1F1956094; Wed, 27 May 2026 12:06:02 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id BEAF51684; Wed, 27 May 2026 12:06:01 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH 1/4] KVM: x86: remove nested_mmu from mmu_is_nested() Date: Wed, 27 May 2026 08:05:57 -0400 Message-ID: <20260527120600.20696-2-pbonzini@redhat.com> In-Reply-To: <20260527120600.20696-1-pbonzini@redhat.com> References: <20260527120600.20696-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 Content-Type: text/plain; charset="utf-8" nested_mmu is always stored into vcpu->arch.walk_mmu at the same time as guest_mmu is stored into vcpu->arch.mmu. But nested_mmu is not even a proper MMU, it is only used for page walking; plus the fact that walk_mmu has to be switched at all is just an implementation detail. In the end what matters here is whether the guest is using nested page tables; vmx/nested.c and svm/nested.c check it to see if they are in nEPT or nNPT context respectively. So switch to checking root_mmu vs. guest_mmu, which is a more cogent test. Signed-off-by: Paolo Bonzini --- arch/x86/kvm/x86.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index 38a905fa86de..60ff064de12f 100644 --- a/arch/x86/kvm/x86.h +++ b/arch/x86/kvm/x86.h @@ -290,7 +290,7 @@ static inline bool x86_exception_has_error_code(unsigne= d int vector) =20 static inline bool mmu_is_nested(struct kvm_vcpu *vcpu) { - return vcpu->arch.walk_mmu =3D=3D &vcpu->arch.nested_mmu; + return vcpu->arch.mmu =3D=3D &vcpu->arch.guest_mmu; } =20 static inline bool is_pae(struct kvm_vcpu *vcpu) --=20 2.52.0 From nobody Mon Jun 8 18:57:24 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EFCBB2F7F12 for ; Wed, 27 May 2026 12:06:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883569; cv=none; b=Adf7pn27hIgN63puUC0kxIT24hb89tUatHt9UaNU+TpuWVBd0jIYfnqK+lNPzSnh/z7/3zOqSBa2H/xMlwCLIswsI4mwlMwVqszCAWHu4umAbpWp8lbBq8oqhFUXUTls9bRbXPwuEtQilWES4GH+dUASjzmfE0BqTYLCHHE29uQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883569; c=relaxed/simple; bh=gvEiPlInglo0r74PX397+vNMGGG0xuISgO8KtDoW134=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Abrtq2e48sXJ6uaYoyJyxPp+QXW+pscqEktB5xz1HwtE4NcsS0+Mm1ylVahjeV5dou6WholXJwiLnQj8I+0lDmfr/ZMaeAKnULvKMJgdryY/JsMk6V+E5Qp48AYQJWZc2N0zWWqWpp1p2f4RSrGeGkvC6O7bM4j607UAZiQjhyA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=IcH9jOsY; arc=none smtp.client-ip=170.10.133.124 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) header.d=redhat.com header.i=@redhat.com header.b="IcH9jOsY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779883567; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nya6UNu0l453v6wwHI22O/+8/iCoTX1TEBOmb0+3No0=; b=IcH9jOsYvb4N4C/JO0idnuePOXbOAV3ITpYjAOTQnaPY6DF0jbydGp2efw/Xit6lTv+E3j 1naCLJtDLBgVHEFF+Gw61HwzlQp/fZ/GUKe4FbAk6yd+IZ8Vs/G41AvLOs8AEdVK2kGGvv VwYUSHwvjpZP363TbKDbs3c1cNkxisI= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-622-iqONmE_xMwuSF1GvHH86sA-1; Wed, 27 May 2026 08:06:03 -0400 X-MC-Unique: iqONmE_xMwuSF1GvHH86sA-1 X-Mimecast-MFC-AGG-ID: iqONmE_xMwuSF1GvHH86sA_1779883562 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B0CE91956096; Wed, 27 May 2026 12:06:02 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 5520C1681; Wed, 27 May 2026 12:06:02 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH 2/4] KVM: nVMX: remove unnecessary code in prepare_vmcs02 Date: Wed, 27 May 2026 08:05:58 -0400 Message-ID: <20260527120600.20696-3-pbonzini@redhat.com> In-Reply-To: <20260527120600.20696-1-pbonzini@redhat.com> References: <20260527120600.20696-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 Content-Type: text/plain; charset="utf-8" The late vmwrite of the PDPTRs in prepare_vmcs02() is redundant, because every write it does was already performed by prepare_vmcs02_rare earlier in the same prepare_vmcs02 call. In particular: - load_guest_pdptrs_vmcs12 =3D=3D true implies that prepare_vmcs02_rare() r= an - the assignment to load_guest_pdptrs_vmcs12 matches the gate in prepare_vmcs02_rare(), other than having one that checks !hv_evmcs and the other !nested_vmx_is_evmptr12_valid(vmx) - the condition for the late move is a strict subset of the one in prepare_vmcs02_rare(), because the former checks nested_cpu_has_ept(vmcs12), which implies enable_ept, and on top it narrows it further by ANDing is_pae_paging(vcpu) Signed-off-by: Paolo Bonzini --- arch/x86/kvm/vmx/nested.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index c1be8ef882b8..f86a12fc29ec 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -2721,14 +2721,10 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, st= ruct vmcs12 *vmcs12, { struct vcpu_vmx *vmx =3D to_vmx(vcpu); struct hv_enlightened_vmcs *evmcs =3D nested_vmx_evmcs(vmx); - bool load_guest_pdptrs_vmcs12 =3D false; =20 if (vmx->nested.dirty_vmcs12 || nested_vmx_is_evmptr12_valid(vmx)) { prepare_vmcs02_rare(vmx, vmcs12); vmx->nested.dirty_vmcs12 =3D false; - - load_guest_pdptrs_vmcs12 =3D !nested_vmx_is_evmptr12_valid(vmx) || - !(evmcs->hv_clean_fields & HV_VMX_ENLIGHTENED_CLEAN_FIELD_GUEST_GRP1); } =20 if (vcpu->arch.nested_run_pending && @@ -2831,15 +2827,6 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, str= uct vmcs12 *vmcs12, if (enable_ept) vmcs_writel(GUEST_CR3, vmcs12->guest_cr3); =20 - /* Late preparation of GUEST_PDPTRs now that EFER and CRs are set. */ - if (load_guest_pdptrs_vmcs12 && nested_cpu_has_ept(vmcs12) && - is_pae_paging(vcpu)) { - vmcs_write64(GUEST_PDPTR0, vmcs12->guest_pdptr0); - vmcs_write64(GUEST_PDPTR1, vmcs12->guest_pdptr1); - vmcs_write64(GUEST_PDPTR2, vmcs12->guest_pdptr2); - vmcs_write64(GUEST_PDPTR3, vmcs12->guest_pdptr3); - } - if ((vmcs12->vm_entry_controls & VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL) && kvm_pmu_has_perf_global_ctrl(vcpu_to_pmu(vcpu)) && WARN_ON_ONCE(__kvm_emulate_msr_write(vcpu, MSR_CORE_PERF_GLOBAL_CTRL, --=20 2.52.0 From nobody Mon Jun 8 18:57:24 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 55F623CFF50 for ; Wed, 27 May 2026 12:06:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883567; cv=none; b=nDuvzluwSU1zr9Pw9WoHAuyCGCD6pFJxY2156eK5QH0FskXghFOcUt1kroE8tUv56M7L+daSAC80rJFZRhKMoROJydiNE1ZBYHG2B+LK/l0J2hgLhI+K00+h82II5+3D38JxJl03yxREPxfuUeT5LTp0tjPR/9Dh2izK85BbOeg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883567; c=relaxed/simple; bh=hcnMy0pk5y4k5dWyzFYhPys6XtCcu6uR92E9DHF9ysg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=m8N8DYN3PPfXph66VL1Y9M/r9GQzQ47EndUvP/SqZKuM7c9BWabHIbJBQ4VCFM1sC3q0qwE+SrOkYbGiTN8SPpR4Hpt9pA/LIsOPxaFMP4sVqK2fxoc9sq4AwWIhmc/rd9sHMtishDG9o8XXa79UfQBlJQyW9xWqsL5IaE0EXmE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=CEnXmLpD; arc=none smtp.client-ip=170.10.129.124 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) header.d=redhat.com header.i=@redhat.com header.b="CEnXmLpD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779883565; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I9+0F9zn7InsarGAuIZCAI//xzyMzOUExsQx9OexxrE=; b=CEnXmLpDhCautLGFexxBvQ5nWXRD/8nHNZ8owu8kX26P5BNRGl4qOcX0yfXlEAa0puUoRz VXpqmHq2BOrkRo3z/HK1Qt86rxXDu8/WonN4k8PvyzFgBp1YYYTjK2apyfNtVZ4FHJSykR hk045TPAp/EVnkBOZbZy++LrYNiJIj4= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-635-UxCoixJqOmaIDa5fxcNbYw-1; Wed, 27 May 2026 08:06:04 -0400 X-MC-Unique: UxCoixJqOmaIDa5fxcNbYw-1 X-Mimecast-MFC-AGG-ID: UxCoixJqOmaIDa5fxcNbYw_1779883563 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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3D8151956094; Wed, 27 May 2026 12:06:03 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D729A1681; Wed, 27 May 2026 12:06:02 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH 3/4] KVM: nSVM: invalidate cached PDPTRs across nested NPT transitions Date: Wed, 27 May 2026 08:05:59 -0400 Message-ID: <20260527120600.20696-4-pbonzini@redhat.com> In-Reply-To: <20260527120600.20696-1-pbonzini@redhat.com> References: <20260527120600.20696-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 Content-Type: text/plain; charset="utf-8" When L2 runs under nested NPT and uses PAE paging, KVM's cached PDPTRs in mmu->pdptrs[] can hold stale or wrong values after nested transitions and across migration restore, because both nested_svm_load_cr3() and svm_get_nested_state_pages() only refresh PDPTRs on the !nested_npt path. The user-visible bug is on migration restore of an L2 running with nested NPT and 32-bit PAE paging, if userspace uses KVM_SET_SREGS rather than KVM_SET_SREGS2. In that case, load_pdptrs() leaves VCPU_EXREG_PDPTR marked as available, and kvm_pdptr_read() will use a stale translation that used L1 GPAs instead of L2 nGPAs. svm_get_nested_state_pages() runs on first KVM_RUN but skips the refresh because nested_npt_enabled() is true. The CPU itself reads L2's PDPTRs correctly from memory via L1's NPT, but KVM-side walking of guest PAE page tables uses the bogus cached values. Unlike Intel's GUEST_PDPTR0..3 fields in the VMCS, SVM has no VMCB-cached PDPTR state: the in-memory PDPTEs at the current CR3 are the only source of truth, and svm_cache_reg(VCPU_EXREG_PDPTR) simply reloads them from memory via load_pdptrs(). Clearing the avail bit (and the dirty bit because !avail/dirty is invalid) to force a reload when PDPTRs as needed fixes the bug. Do the same for nested_svm_load_cr3()'s nested_npt branch, so that the invariant "PDPTRs need reloading" is handled similarly for both immediate and deferred loading. Signed-off-by: Paolo Bonzini --- arch/x86/kvm/kvm_cache_regs.h | 8 ++++++++ arch/x86/kvm/svm/nested.c | 27 ++++++++++++++++++--------- 2 files changed, 26 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/kvm_cache_regs.h b/arch/x86/kvm/kvm_cache_regs.h index 2ae492ad6412..6bae5db5a54e 100644 --- a/arch/x86/kvm/kvm_cache_regs.h +++ b/arch/x86/kvm/kvm_cache_regs.h @@ -77,6 +77,14 @@ static inline bool kvm_register_is_dirty(struct kvm_vcpu= *vcpu, return test_bit(reg, vcpu->arch.regs_dirty); } =20 +static inline void kvm_register_mark_for_reload(struct kvm_vcpu *vcpu, + enum kvm_reg reg) +{ + kvm_assert_register_caching_allowed(vcpu); + __clear_bit(reg, vcpu->arch.regs_avail); + __clear_bit(reg, vcpu->arch.regs_dirty); +} + static inline void kvm_register_mark_available(struct kvm_vcpu *vcpu, enum kvm_reg reg) { diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index 3d1fd1776e19..aa5a1d8ea136 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -680,9 +680,12 @@ static int nested_svm_load_cr3(struct kvm_vcpu *vcpu, = unsigned long cr3, if (CC(!kvm_vcpu_is_legal_cr3(vcpu, cr3))) return -EINVAL; =20 - if (reload_pdptrs && !nested_npt && is_pae_paging(vcpu) && - CC(!load_pdptrs(vcpu, cr3))) - return -EINVAL; + if (reload_pdptrs && is_pae_paging(vcpu)) { + if (nested_npt) + kvm_register_mark_for_reload(vcpu, VCPU_REG_PDPTR); + else if (CC(!load_pdptrs(vcpu, cr3))) + return -EINVAL; + } =20 vcpu->arch.cr3 =3D cr3; =20 @@ -2055,15 +2058,21 @@ static bool svm_get_nested_state_pages(struct kvm_v= cpu *vcpu) if (WARN_ON(!is_guest_mode(vcpu))) return true; =20 - if (!vcpu->arch.pdptrs_from_userspace && - !nested_npt_enabled(to_svm(vcpu)) && is_pae_paging(vcpu)) + if (is_pae_paging(vcpu)) { /* - * Reload the guest's PDPTRs since after a migration - * the guest CR3 might be restored prior to setting the nested - * state which can lead to a load of wrong PDPTRs. + * After migration, CR3 may have been restored before + * KVM_SET_NESTED_STATE, so the PDPTR load into mmu->pdptrs[] + * may have treated CR3 as an L1 GPA. For nNPT, drop the + * cache so the next access reloads them with the proper + * nGPA translation. For !nNPT, reload eagerly unless userspace + * already supplied authoritative PDPTRs via KVM_SET_SREGS2. */ - if (CC(!load_pdptrs(vcpu, vcpu->arch.cr3))) + if (nested_npt_enabled(to_svm(vcpu))) + kvm_register_mark_for_reload(vcpu, VCPU_REG_PDPTR); + else if (!vcpu->arch.pdptrs_from_userspace && + CC(!load_pdptrs(vcpu, vcpu->arch.cr3))) return false; + } =20 if (!nested_svm_merge_msrpm(vcpu)) { vcpu->run->exit_reason =3D KVM_EXIT_INTERNAL_ERROR; --=20 2.52.0 From nobody Mon Jun 8 18:57:24 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CDEC3CFF62 for ; Wed, 27 May 2026 12:06:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883570; cv=none; b=j2QBUZTK09Ba+Om65vUuK+lwN+t88LEwsUNFHBT5rViL32X9Tejp8LYPDQIKK1dcL3pxZa/BzFrTmvG4wvP1407xrcjolIPw+/+Q8MrAUNKqu6QKCFMv2sWydR3rcGOBPUKF0wZw1b898zE8U5hm+ZRrvgjh69zA2H/E6rmFeLQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883570; c=relaxed/simple; bh=0t/PwehJOhkZ25cyQ8uMWFa2qQhoO6sby96IaT7I5cs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=EkHvU5XsKLR9lWUttxmGt6W7dOxpaQUPUSK6FQyQfPSX6SQFMKLIVdDIfFGDaHjfFe2A1BgXzojr55bF2NeKQtgut+jEpbwHTYAKU0m3pzTMktjPYMBY/JiBkWDXelLt8JUzIKPs8Z0MhHcdDCVExXDceOlQuKwnZ/4c+igFbyU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TCN7ehDe; arc=none smtp.client-ip=170.10.129.124 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) header.d=redhat.com header.i=@redhat.com header.b="TCN7ehDe" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779883568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8eLGDCCntmNXCbQ4uxKMEWyY9/qJPquq+xtWLIx9isI=; b=TCN7ehDevFG62ippm2fHtkQQrSk8WpjccdEmFMTzatJsRMUALNMqP991t5Dx0ZBzWNPNfn izFb3LfajPERPBzvL6kMFPrNsWjz/uFjL+Mi1sG+RzY3EM0LiL3oSPoZWrDU4i+/DAzyy0 habTA9sZbqk7LaHpUh+UK/xwx9UuGbw= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-665-jX1e7Ex1ODOh-bwusQdEcg-1; Wed, 27 May 2026 08:06:04 -0400 X-MC-Unique: jX1e7Ex1ODOh-bwusQdEcg-1 X-Mimecast-MFC-AGG-ID: jX1e7Ex1ODOh-bwusQdEcg_1779883564 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DF1BF195609F; Wed, 27 May 2026 12:06:03 +0000 (UTC) Received: from virtlab1023.lab.eng.rdu2.redhat.lab.eng.rdu2.redhat.com (virtlab1023.lab.eng.rdu2.redhat.com [10.8.1.187]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 63A611681; Wed, 27 May 2026 12:06:03 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH 4/4] KVM: x86: check that kvm_handle_invpcid is only invoked with shadow paging Date: Wed, 27 May 2026 08:06:00 -0400 Message-ID: <20260527120600.20696-5-pbonzini@redhat.com> In-Reply-To: <20260527120600.20696-1-pbonzini@redhat.com> References: <20260527120600.20696-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 Content-Type: text/plain; charset="utf-8" This is true for both Intel and AMD. On Intel, "enable INVPCID" is set unconditionally if supported, but the vmexit is triggered by the "INVLPG exiting" control which is disabled by enable_ept. On AMD, KVM can intercept INVPCID if NPT is enabled but only in order to inject #UD in the guest. Signed-off-by: Paolo Bonzini --- arch/x86/kvm/x86.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index fc0924389398..1913efef6c39 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -14350,6 +14350,9 @@ int kvm_handle_invpcid(struct kvm_vcpu *vcpu, unsig= ned long type, gva_t gva) return 1; } =20 + if (WARN_ON_ONCE(tdp_enabled)) + return 0; + pcid_enabled =3D kvm_is_cr4_bit_set(vcpu, X86_CR4_PCIDE); =20 switch (type) { --=20 2.52.0