From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.216.69 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793214192; b=Ap4tFMcgX3hVPqeNfwBbCO0U05Mqq4lS6oHZL5wSuyIVn0U0xQfHtoqlU1DPCV3tEjbd bnhTudI3qG6dG6XR85SoZAh1FQTKK6+9qB4T7DTz5wO8P3Ty1YJ2OyxP9b7RCPdsYb8nJ IH2ojVpJQNUbNNmgRUllV+Wr+iSIXFVtbXnEc1NdK28Y7lcAPv7WUbGUIx1QN4YjPgcg2 O7KBCiykwDwbAUc4vpnnn/bM/2/MIb5aaGGgmZwbJnT2hSxpV4e3zhSXP/aTn5oa7jfqc REESxf5yH6nySvk0Tcy00jB6U8oR1UkfUwN1TsXM2Hi6j5QBhGJ4HFJi3VxuAzWXk5Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793214192; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Received:Reply-To:Date: In-Reply-To:Mime-Version:References:X-Mailer:Message-ID:Subject:From: To:Cc:Content-Type; bh=jCCEmu80ia44kI2vyDb6i59VDXRIs93I0WproZ1Xw/A=; b=BkIbzS33nfN95093Yfd0Oft6PO1CHw1WSQGCf6PS+gxqS8d+Q0gWfZNlw03otLmTd726 0gK19cWi5+jm4MHXHRUHckX/0CpnZOPUCZEfnrULrtyygyTl4wMNl9uPodrw9JUvSla1r amswk3PMgD/qvSq7w/1iZ77bKqN4gP+KVKcijTNbGUT21boqP3X7Wq+/E4bwjtfUHJ1Lh 3EB6Bb0Ye8tqzcXmF6YX9WrTETmo/yGldpmGkHZegXPMmyPW+v1EhQslFk0zPj4klkyM2 4vOAB99Fal3YsV/uFn89pSdk4C+FEk8XIcVZxHeBmhN2yo4u1ZescJ/17cuF0W9W/bQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20260707 header.b=VKCoKKaW; arc=none smtp.remote-ip=209.85.216.69 Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4EA1D60A6F43 for ; Wed, 28 Oct 2026 19:03:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 4EA1D60A6F43 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, unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20260707 header.b=VKCoKKaW Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-3abb4c24125so1234681a91.3 for ; Wed, 28 Oct 2026 12:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20260707; t=1793214191; x=1793818991; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id :reply-to:content-type; bh=jCCEmu80ia44kI2vyDb6i59VDXRIs93I0WproZ1Xw/A=; b=VKCoKKaWzE2ZwVdJNmZ2sHfiG+KYy5lqQ6i0TsdahSfguB8+ESncbH3xe7BAm5PMEr Q2jNZybsr8T/OPE4rcgH6TJFsrEHx25QQodbvFRK9rmyThmhDrBShJEtAZPC5lf7Dw6Z n0j2lj1MdfRpm2YvS/mAQC7pHLFF02JaJLFKDf/j/2o6AD5FxpQ2Mykl2OvaoWH/q5SO 11SmykgHIBFTO4Wqjb/oz7PvUtp0kSs/YxJVlLruwf+/gTk9MyKnG/GmkJvBgumlE//6 +vR0EfuEnrgATAOhzav2N012MxlYmtHXZiPybtbyC9U5lzJn9XmnQ3/lZZ+pED1y9sIm /ArA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793214191; x=1793818991; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=jCCEmu80ia44kI2vyDb6i59VDXRIs93I0WproZ1Xw/A=; b=vlGuHJIuoWIvbwE8H7QO86K4qr6K3vUjhnnA6y6txUO0/xf5rUkkVjYZ3e8qa80X4U oGRm6nEPnXJzUYfT1rlP73fC1oFrttlwjI2GlqGiMfsG2skZjjQhzWpNAFHOUEy4LYX/ piOdYypjI05Nfa+WCVCzW/vkbMTSVe3d2iEHywhWsEJrQmCE8Z7WXX/Q8H94kylDLqWI CV9ctJ7+gdDNhfCWaBzfzyKc5Y9kD6S3O5U3tqi5tv8hGN5B96mnq9k90DIDdHr/ClYW 1+/GHFyhjpD4skBS6wA2KObzqziiu6HwH6h+ELwOk8g+Km/d+d9xzs9ejhOdVX98nnyE r/BA== X-Forwarded-Encrypted: i=1; AKwUvBxpOYLQb5VVpNZMVEegpKEdt9ldJg8AUQwXz+mMmrVXIhV/4wfetfSE/pn+S0T2pMP39mSijWYxk8Bd@vger.kernel.org X-Gm-Message-State: AFq9FYJ68w5PWKUpWz6y3CwVMF1Bod95ySMUHDvWnbIo2qgFrt0MBlfe W1htYS5V/aQTV4ux52VS1ygt/myDXHwTbMdaI0Ng5bz5P/Ke/di/8V8qV+6WdOnIGuLZ4xuW5LV VF+tK9g== X-Received: from pghv3.prod.google.com ([2002:a63:f203:0:b0:cd6:b233:e4aa]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4b06:b0:3ab:b64:5893 with SMTP id 98e67ed59e1d1-3ae581bc654mr2418362a91.53.1793214190430; Wed, 28 Oct 2026 12:03:10 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 28 Oct 2026 12:02:59 -0700 In-Reply-To: <20261028190259.1819571-1-seanjc@google.com> X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 References: <20261028190259.1819571-1-seanjc@google.com> X-Mailer: git-send-email 2.56.0.313.g2479322e68-goog Message-ID: <20261028190259.1819571-8-seanjc@google.com> Subject: [PATCH 7/7] KVM: Drop kvm_vcpu_should_kick() and use kvm_request_needs_ipi() From: Sean Christopherson To: Marc Zyngier , Oliver Upton , Tianrui Zhao , Bibo Mao , Huacai Chen , Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sean Christopherson , Paolo Bonzini Cc: Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Nicholas Piggin , Atish Patra , Alexandre Ghiti , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Stefan Teodorescu Content-Type: text/plain; charset="UTF-8" Drop kvm_vcpu_should_kick() in favor of kvm_request_needs_ipi() to fix a bug where KVM will fail to wait for a vCPU to exit guest mode if the vCPU was already marked as EXITING_GUEST_MODE by a concurrent non-waiting kick. Because kvm_vcpu_should_kick() (was kvm_arch_vcpu_should_kick()) only waits (and sends an IPI to do so) if the target vCPU is fully IN_GUEST_MODE, the sending task will proceed even though it hasn't actually guaranteed the vCPU as fully exited the guest. The flaw is most problematic for SNP VMSA invalidation with in-place gmem conversion, as KVM invokes kvm_gmem_invalidate_start() => rmp_make_shared() (via kvm_gmem_make_shared() in quick succession when in-place conversion is enabled. I.e. if the target has been marked as EXITING_GUEST_MODE but has not yet received the other kicker's IPI, then updating the RMP will fail as the VMSA is still in-use and subsequent accesses to the page will encounter unexpected RMP #PFs. Note, the bug exists and affects VMSA invalidation even without in-place conversion, but is significantly more difficult to hit as PUNCH_HOLE and .release() have to wade through a lot more code and several locks to get from invalidation to kvm_gmem_free_folio(). Note #2, currently only x86 uses kvm_make_request_and_kick(), i.e. this is a glorified nop for all other architectures as the KVM_REQUEST_WAIT path is never taken. Fixes: 309d28576f0a ("KVM: SVM: Fix SNP AP destroy race with VMRUN") Fixes: d1a3c2162334 ("KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped") Reported-by: Stefan Teodorescu Signed-off-by: Sean Christopherson --- virt/kvm/kvm_main.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index f1792256576b..f99a714698e3 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -191,7 +191,6 @@ void vcpu_put(struct kvm_vcpu *vcpu) } EXPORT_SYMBOL_FOR_KVM_INTERNAL(vcpu_put); -/* TODO: merge with kvm_vcpu_should_kick */ static bool kvm_request_needs_ipi(struct kvm_vcpu *vcpu, unsigned req) { int mode = kvm_vcpu_exiting_guest_mode(vcpu); @@ -209,11 +208,6 @@ static bool kvm_request_needs_ipi(struct kvm_vcpu *vcpu, unsigned req) return mode == IN_GUEST_MODE; } -static int kvm_vcpu_should_kick(struct kvm_vcpu *vcpu) -{ - return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE; -} - static void ack_kick(void *_completed) { } @@ -3935,7 +3929,7 @@ void __kvm_vcpu_kick(struct kvm_vcpu *vcpu, int req, bool force) /* * Note, the vCPU could get migrated to a different pCPU at any point - * after kvm_vcpu_should_kick(), which could result in sending an + * after kvm_request_needs_ipi(), which could result in sending an * IPI to the previous pCPU. But, that's ok because the purpose of the * IPI is to force the vCPU to leave IN_GUEST_MODE, and migrating the * vCPU also requires it to leave IN_GUEST_MODE @@ -3944,7 +3938,7 @@ void __kvm_vcpu_kick(struct kvm_vcpu *vcpu, int req, bool force) * check also modifies vcpu->mode and KVM PPC needs to avoid that side * effect for unknown historical reasons. */ - if (force || kvm_vcpu_should_kick(vcpu)) { + if (force || kvm_request_needs_ipi(vcpu, req)) { cpu = READ_ONCE(vcpu->cpu); if (cpu != me && (unsigned int)cpu < nr_cpu_ids && cpu_online(cpu)) { /* -- 2.56.0.313.g2479322e68-goog