From nobody Mon May 25 08:11:55 2026 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D0823D9DA6 for ; Fri, 15 May 2026 17:15:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778865340; cv=none; b=P3C9a+hEnkwYyIVhLYYksq3BS3EwlXoMaDm2nd6LGLjKwrqrjuVKoLK5NGNutT0gf4P3G61jFTxX6FE4UHfzImTTAlaSbAzrMt1b60eWIoiYO4C9SfK7DAaI6OPq/HGxiIbmhD4TTxml5rc2pWTlz4wi7R0tmUA13lu+xV9IE5A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778865340; c=relaxed/simple; bh=Iy7SrJOHrWMF10VoqMzA4L8S2oZcfVCfMXJj9qvp+U0=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=kkDvv6plH+MhB5EI8nYFPzm79vXEd2zgMDuxZvZj5kKeAx1PLLKwk/55yaZACcotBEkx++WcG3w0DoNEitBYynrWGvVyBGdp1QDz/zMue64SR+tv5id1/ctkYjyNKfxH9vvRYtFT+n6TdkvzjoXe4T1afoWGIcTx2w+uZVmFYQ4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=TJReTuNJ; arc=none smtp.client-ip=209.85.214.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="TJReTuNJ" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2ba268cb5e6so856805ad.1 for ; Fri, 15 May 2026 10:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778865339; x=1779470139; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc :subject:date:message-id:reply-to; bh=FXne7n9YlZuhy/YYik1SkDFKzdHy9NFNuwS5NyaEXnA=; b=TJReTuNJnYk3yJ14z5PgrnMm7rzWBg9exuhWntYsQ3Xa/Ec3FP/KVQ1MDrXhbjbORG d3jPqkxWGL0jPL6dLwHpbSnRQzPx9wOFzoJDv4J1pb3nb8CqrBTEH2uIwu32CNfmNFga O6jNvyVvc706Hqk4a29D2lub6u18Ge8boyrUWsX5VhgwPm5uoQRJKVkUiuH2sTwb3J7B IR2KaajThrqo+IUJUt7rJ6mVVsSwhnmL9abzYRMxwP4l9a+PrHW3ugpzoJJdgqFXfuKq 1glLZ+etYWfBP19E/POINjlObYc+jRxQNWUQKIm4T+/fklNGXhsjIXxkuvS1+I9SrFs9 fWBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778865339; x=1779470139; h=cc:to:from:subject:message-id:mime-version:date:reply-to :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FXne7n9YlZuhy/YYik1SkDFKzdHy9NFNuwS5NyaEXnA=; b=XCH+5a1sOmqRJROhWnpinwyn5cO3FHGex3TMcVa2LzuMjiC98mXf/hLrVQlyVNotdF vXkYIzId0TuSRT5bVEOVAUIPaDx/t9YvgRMc16JzArPUcI5hstg9b8+0d9DrRZyFG5np dOgfCAaA2Uoq2gRB8cAV2JjBeeLbrKlJmuOvi4UIeBkyi8uaob6giVgz7gycOkI7cSle mbvr7iWKUlfi9mENXKOtViiTUdyM27OB6dh9RDjJGJl8V+8Hoj8H3Lf2d24Gr5IGCU1B qnlm4jIm/vb49z6i38pVHGQc55bXZdQ7ndYS7C5b4h6RGVIKywpQ+zW8O3ShlieWP6rL AfOg== X-Forwarded-Encrypted: i=1; AFNElJ/lRtGHH7n3Op2XZiJcGbt0CTbq53WGCPYT2efBTfS6YRutW2TZlmp12pdEyPdbRDPZecpch5Jd8cokOT4=@vger.kernel.org X-Gm-Message-State: AOJu0Yzwnnh93k2nZUduLPM2KOE37Ox9IxuNEZ3d+4u5/4ylmZvSPzLu f0ybRePpNoNqA0tSEL1LQEM9vqEChhB7v7vTIttC9b+NXL4e3oEOrVKu2QL6scWDgiXQ9dLzMX/ esWE+2g== X-Received: from pjvf3.prod.google.com ([2002:a17:90a:da83:b0:369:3fa4:a760]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:568d:b0:367:bf0c:54e9 with SMTP id 98e67ed59e1d1-36951cbd45emr5849335a91.21.1778865338437; Fri, 15 May 2026 10:15:38 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 15 May 2026 10:15:36 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.54.0.563.g4f69b47b94-goog Message-ID: <20260515171536.1841645-1-seanjc@google.com> Subject: [PATCH] KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Naveen N Rao Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Flush the current TLB when xAVIC *or* x2AVIC is activated, as KVM is (apparently) responsible for purging TLB entries when transitioning from xAVIC to x2AVIC. The APM says a whole lot of nothing about TLB flushing with respect to (x2)AVIC, but empirical data strongly suggests hardware also does a whole lot of nothing. Failure to flush the TLB when enabling x2AVIC can lead to guest accesses to the APIC base address getting incorrectly redirected to the virtual APIC page. The flaw most visibly manifests as failures in KVM-Unit-Test's verify_disabled_apic_mmio() testcase when x2APIC is enabled (though for reasons unknown, the test only reliably fails with EFI builds). Fixes: 0ccf3e7cb95a ("KVM: SVM: Flush the "current" TLB when activating AVI= C") Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode= ") Cc: stable@vger.kernel.org Cc: Naveen N Rao (AMD) Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/avic.c | 35 +++++++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index adf211860949..e8bd60156941 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -206,6 +206,35 @@ static void avic_activate_vmcb(struct vcpu_svm *svm) =20 svm_clr_intercept(svm, INTERCEPT_CR8_WRITE); =20 + /* + * Flush the TLB when enabling (x2)AVIC and when transitioning between + * xAVIC and x2AVIC, as the CPU may have inserted a TLB entry for the + * "wrong" mapping. + * + * KVM uses a per-VM "scratch" page to back the APIC memslot, because + * KVM also uses per-VM page tables *and* maintains the page table (NPT + * or shadow page) mappings for said memslot even if one or more vCPUs + * have their local APIC hardware-disabled or are in x2APIC mode, i.e. + * even if one or more vCPUs' APIC MMIO BAR is effectively disabled. + * + * If xAVIC is fully enabled, hardware ignores the physical address in + * KVM's page tables, i.e. in the leaf SPTE for the APIC memslot, and + * instead redirects the access to the AVIC backing page, i.e. to the + * vCPU's virtual APIC page. If xAVIC is not enabled (APIC is either + * hardware-disabled or in x2APIC mode), then guest accesses will use + * the page table mapping verbatim, i.e. will access the per-VM scratch + * page, as normal memory. + * + * In both cases, the CPU is allowed to cache TLB entries for the APIC + * base GPA. So, KVM needs to flush the TLB when enabling xAVIC, as + * accesses need to be redirected to the virtual APIC page, but the TLB + * may contain entries pointing at the scratch page. KVM also needs to + * flush the TLB when enabling x2AVIC, as accesses need to go to the + * scratch page, but the TLB may contain entries tagged as xAVIC, i.e. + * entries pointing to the vCPU's virtual APIC page. + */ + kvm_make_request(KVM_REQ_TLB_FLUSH_CURRENT, &svm->vcpu); + /* * Note: KVM supports hybrid-AVIC mode, where KVM emulates x2APIC MSR * accesses, while interrupt injection to a running vCPU can be @@ -219,12 +248,6 @@ static void avic_activate_vmcb(struct vcpu_svm *svm) /* Disabling MSR intercept for x2APIC registers */ avic_set_x2apic_msr_interception(svm, false); } else { - /* - * Flush the TLB, the guest may have inserted a non-APIC - * mapping into the TLB while AVIC was disabled. - */ - kvm_make_request(KVM_REQ_TLB_FLUSH_CURRENT, &svm->vcpu); - /* Enabling MSR intercept for x2APIC registers */ avic_set_x2apic_msr_interception(svm, true); } base-commit: a9512a611bd030088f13477258d1f8103cceaa40 --=20 2.54.0.563.g4f69b47b94-goog