From nobody Thu Sep 24 18:40:04 2026 Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (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 5456A4ED182 for ; Mon, 21 Sep 2026 17:44:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.198 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012691; cv=none; b=mLGsO9ZQ2L8iYgMshfsSxpajrEEGZmF0jWIXQ3GQ5tCD0kbjG51bpwL/FwDjXhz+MilcErGJj0i8K0nq7H6HNuJex/t+jAjQB76k8tucwuIxYkNYicrlRhUz7o5L2qh2pDol8k5tHLfBwZo95VfuTFS0XVbB4HIFwADuCwE5h8Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012691; c=relaxed/simple; bh=Pm2NqTs6oRcRC4pVvxFdi78nyABlZFM4rmakGlSjCpY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=W8HYn6izBMgNY2qC+/vr5bZSuh/ViabPDy+3fJwSFl+f1qxZrFNASd2b3phMKp67mKwHbYgCc7YA1ha+SHZLHEpROXC5boe6eQ/pyB9vT2PKt9Jnk9Ou8hIdT2FDoDm158CMBIOaSpNzAibCsba6PFxxeD5IIAIf556rZhfZDxY= 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=KGT20HV4; arc=none smtp.client-ip=209.85.210.198 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="KGT20HV4" Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-86b4048367cso4305711b3a.2 for ; Mon, 21 Sep 2026 10:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790012689; x=1790617489; 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=ZLfRYJewP8aR3Y4V2zbyCdDW63inecBdjfc5u4aaKpU=; b=KGT20HV4ORvKVgmu/kWoIDfdPBrIW+iw/KC01tQxxiB4PkDg8bxOEhgFYslUAqYkXw FDpxDkNy1P0lsNOQjhZg4yXvc1dL9UBweQNwDQoJKju9JzY7tVJArL/B0BUPOOGpWT8K 3fRh/iceuHBchjJMSyfd0KGwmR/j0JD+vPGB578qEsJLqT80OUwGcAtYVUxdyA86fNRp mUaOHq6KPnbuGcpPpRyI0pO9vtsQ5zjjdpxKSUDH1oGWlCrhobsy8pFSc1126FD62AJW qK1SpjubJxBimDh7u7srgwQGL24rqplorOYWbrtr3eUPrdS3pExPeyZVeATga3SGv63+ 6AZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790012689; x=1790617489; 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=ZLfRYJewP8aR3Y4V2zbyCdDW63inecBdjfc5u4aaKpU=; b=JubzEP8sJ8Wpud8aQ30DV/2OaFc+2/jdAREe9WLfOuYxDi1J9K3XzHxxia2vbyz+wZ XC1gASlouqh5Yn8gZv1N125PiQWV9vJ86V+VRaU9V4ERarHG10rTOk/BeN3Xcu/8C85S jxEKKzvBr3X/HbbglebWX4lL82xRpSWvN5Qjwx6qT3GCV5oJHEZ4RrnvyKzbeFCW4FmV tWnFftp9qRdHyK/tQWccD9Li/mWohY5Iqqr1ga22rnINbyHQzIUDNbT6w7ShfDzHIYcu SMHWZ4+rIfTgPc8dxi6rQXFZ7OeaH+Uubs3ciyAMtVGVrvfyWdEzl+bRNwwJ7tQGR+v5 injw== X-Forwarded-Encrypted: i=1; AKwUvByI5GYHtd1LwxNxs9WaO2oLUThtHFaHTZ8kiXurpRDMjarjqAwjPb6FVLTMKiaZdK8iZrMfJNbLYBUlGpI=@vger.kernel.org X-Gm-Message-State: AFuF++lAmoIcIYDTfjy7Ms/fhv3S5UET69tFeobLvU20DCozjO5RDnrq G0XZiQ0HD6cyrBJqCWlOv87gfDSR5YY2qHtDF4QUBF5BM+j0ko1ybb5/1eV9XqP+1JzN4pHAvDd /NVg7uA== X-Received: from pfbgk3.prod.google.com ([2002:a05:6a00:8483:b0:873:d536:aebe]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:12dd:b0:86b:73b4:30fa with SMTP id d2e1a72fcca58-874dc0ff42cmr17041050b3a.11.1790012688332; Mon, 21 Sep 2026 10:44:48 -0700 (PDT) Reply-To: Sean Christopherson Date: Mon, 21 Sep 2026 10:44:39 -0700 In-Reply-To: <20260921174445.911676-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260921174445.911676-1-seanjc@google.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog Message-ID: <20260921174445.911676-2-seanjc@google.com> Subject: [PATCH v2 1/7] KVM: Reject attempts to lock all vCPUs if vCPU creation is in-progress From: Sean Christopherson To: Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sean Christopherson , Paolo Bonzini , Kiryl Shutsemau , Rick Edgecombe Cc: Nicholas Piggin , Atish Patra , Alexandre Ghiti , Dave Hansen , linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, Jean-Christophe Guillain , "=?UTF-8?q?Pawe=C5=82=20S?=" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Reject locking of all vCPUs if vCPU creation is in-progress, i.e. if the number of "created" vCPUs doesn't match the number of "onlined" vCPUs. It's simply not possible to guarantee that KVM has truly locked all vCPUs if one or more vCPUs are actively being created. Holding kvm->lock does prevent in-flight vCPUs from being fully onlined, but it's infeasible for common KVM to know whether or not that provides sufficient protection. In practice, this is likely a minor bug fix for the ARM and RISC-V usage of kvm_trylock_all_vcpus(), and a glorified nop for everything else. E.g. ARM's kvm_timer_vcpu_init() can race kvm_vm_ioctl_set_counter_offset() with respect to observing KVM_ARCH_FLAG_VM_COUNTER_OFFSET. Opportunistically drop x86's existing manual checks on vCPU creation being in-progress as all of x86's checks immediately precede or follow locking of all vCPUs. Leave arm64 and RISC-V alone for the moment, as their checks aren't as obviously redundant/equivalent. Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) --- arch/x86/kvm/svm/sev.c | 10 ---------- arch/x86/kvm/vmx/tdx.c | 5 ----- virt/kvm/kvm_main.c | 6 ++++++ 3 files changed, 6 insertions(+), 15 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 5705723f1f41..068f8a236a35 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -1125,9 +1125,6 @@ static int sev_launch_update_vmsa(struct kvm *kvm, st= ruct kvm_sev_cmd *argp) if (!sev_es_guest(kvm)) return -ENOTTY; =20 - if (kvm_is_vcpu_creation_in_progress(kvm)) - return -EBUSY; - ret =3D kvm_lock_all_vcpus(kvm); if (ret) return ret; @@ -2115,10 +2112,6 @@ static int sev_check_source_vcpus(struct kvm *dst, s= truct kvm *src) struct kvm_vcpu *src_vcpu; unsigned long i; =20 - if (kvm_is_vcpu_creation_in_progress(src) || - kvm_is_vcpu_creation_in_progress(dst)) - return -EBUSY; - if (!sev_es_guest(src)) return 0; =20 @@ -2510,9 +2503,6 @@ static int snp_launch_update_vmsa(struct kvm *kvm, st= ruct kvm_sev_cmd *argp) unsigned long i; int ret; =20 - if (kvm_is_vcpu_creation_in_progress(kvm)) - return -EBUSY; - ret =3D kvm_lock_all_vcpus(kvm); if (ret) return ret; diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c index b272c20586a7..58c255256e4c 100644 --- a/arch/x86/kvm/vmx/tdx.c +++ b/arch/x86/kvm/vmx/tdx.c @@ -2728,11 +2728,6 @@ static tdx_vm_state_guard_t tdx_acquire_vm_state_loc= ks(struct kvm *kvm) =20 mutex_lock(&kvm->lock); =20 - if (kvm->created_vcpus !=3D atomic_read(&kvm->online_vcpus)) { - r =3D -EBUSY; - goto out_err; - } - r =3D kvm_lock_all_vcpus(kvm); if (r) goto out_err; diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 65eb26a0520d..78cc090435be 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1363,6 +1363,9 @@ int kvm_trylock_all_vcpus(struct kvm *kvm) =20 lockdep_assert_held(&kvm->lock); =20 + if (kvm_is_vcpu_creation_in_progress(kvm)) + return -EBUSY; + kvm_for_each_vcpu(i, vcpu, kvm) if (!mutex_trylock_nest_lock(&vcpu->mutex, &kvm->lock)) goto out_unlock; @@ -1386,6 +1389,9 @@ int kvm_lock_all_vcpus(struct kvm *kvm) =20 lockdep_assert_held(&kvm->lock); =20 + if (kvm_is_vcpu_creation_in_progress(kvm)) + return -EBUSY; + kvm_for_each_vcpu(i, vcpu, kvm) { r =3D mutex_lock_killable_nest_lock(&vcpu->mutex, &kvm->lock); if (r) --=20 2.55.0.1082.g2b9226bbc0-goog From nobody Thu Sep 24 18:40:04 2026 Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) (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 93F824EE84D for ; Mon, 21 Sep 2026 17:44:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.198 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012693; cv=none; b=fQ7+rHIVO9LD4FhtIg6QhsCDUl2N7zUa+ESVTW76dSttlTq1e/qDsChOXt8zia5gJVMAXPXiLcZ2lAib7EhzHdgPPiX1JIwCugcXV0cEFdCgSOdmAoX0cMzV7JQsrH5LZ+CN5cxIxKJHJ9H7lwhmZWcTcvyEALJeIdZF2AXJdKM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012693; c=relaxed/simple; bh=j8ssnULdPPzVZi4sm7QHZinEQxPvi5qB+JfHrPlZuss=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=bXQe1iLbiH2A5wXs3oIfpg0LuUEG+ixrOXGQAz7xmt2LyM479LcXFan/RFE+bFcm5UXHBlyaXb/4e1Z33iiMoVgwZ/UDxxmU93uZCy+eizsqJTxzSB7LP0ln+1Vc3c3XwqNJNVueY6XdxgvPwEqdYmyb5mf5NxZxpN/gV46NqBM= 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=AcYsIzqN; arc=none smtp.client-ip=209.85.214.198 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="AcYsIzqN" Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2db3734d06dso57066735ad.0 for ; Mon, 21 Sep 2026 10:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790012690; x=1790617490; 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=Hyb3zhkpLvcha2XPZl3y4VqrXuYFCx4NQzeWMijbr/g=; b=AcYsIzqNXuEWViGRHn5SQxdAdfLhJzMsFwrOWZTfw4AKks74XEiA7eaVf8yDY0AU4t FjvvBgOe7FvowqNv7fzKEuo+5gNV6Iff9va3tYFLEDV5flVyIFlYj0GNwTHolr2soTx/ FmfV0mKurMPEN9aNE5WL/u5j9TsTlay05n/9OCCS+sOiM+ud9e1YyjhGtX4+WnhxovWg MJhS16lekyzIRgWSC9HghAXHbYKBqUu6ZdvX4+2i9PHX7SsPOEz1PfVlDa2hT2DysIbU pgZZ+ocxsg6Z8r9ZrIb5s2HwN5NHk7Kp4B88WFvX33bxiKwnCezGE4AK+nogrlVbyZ+A LjsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790012690; x=1790617490; 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=Hyb3zhkpLvcha2XPZl3y4VqrXuYFCx4NQzeWMijbr/g=; b=qxhd8W7xuYgNkB7JyP7iG3JotrWHeTsnRS9ilQnPNluZi829XE9tWTxrrf4RdR5oNy d8q9mdzvlizo93kLOTyLT82rzVDQZX17mi/951iS5Na+ky43ByeqkJ+UDL+e8unSZZZ/ qGRAthbIcp4IcnP9RFMiSLPQ3YV4M2YnZtZhQDwm0p7YQbzOz1+njQxOSURibAaGrlCt HuenkznraNouBYaJmtKNP82ICwVm39RYdblca4p8h456ut/Z/4bNp8wRIU6YpR/SRPsg 6Wn7mEHEJtpnSj1V/VjK0R3lIdlwNrO7Mh0u/05ACzUA0JaDzGCLrNI9wsuW08kYcBjz K2DA== X-Forwarded-Encrypted: i=1; AKwUvBxHJPWTgblB6VM4+h9IQvuU7AiLcH1bt6GgNxIFY2G3euBpbsLOONOTDMBvxCITyOPvE3kZDfStwmu1llI=@vger.kernel.org X-Gm-Message-State: AFuF++nK7vsi3IOxmpoJrsfzT5VTO17/HJMQ6LBLpDDt03yfRMivB4AE TxTVK7uzsEwmKLQ5ID72LhZBOanImbwcaoE/51rnaKJhdnGJKwuITGOpF3UmmUoAd47N+NGEoUc Q74j33w== X-Received: from plaq21.prod.google.com ([2002:a17:903:2055:b0:2dd:1daa:a60c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:f54f:b0:2dd:c053:c207 with SMTP id d9443c01a7336-2df560d81a4mr14415165ad.35.1790012689572; Mon, 21 Sep 2026 10:44:49 -0700 (PDT) Reply-To: Sean Christopherson Date: Mon, 21 Sep 2026 10:44:40 -0700 In-Reply-To: <20260921174445.911676-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260921174445.911676-1-seanjc@google.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog Message-ID: <20260921174445.911676-3-seanjc@google.com> Subject: [PATCH v2 2/7] KVM: arm64: vgic: Rely on vCPU creation check in "trylock all vCPUs" From: Sean Christopherson To: Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sean Christopherson , Paolo Bonzini , Kiryl Shutsemau , Rick Edgecombe Cc: Nicholas Piggin , Atish Patra , Alexandre Ghiti , Dave Hansen , linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, Jean-Christophe Guillain , "=?UTF-8?q?Pawe=C5=82=20S?=" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Now that KVM's APIs for locking all vCPUs return -EBUSY if vCPU creation is in-progress, drop the manual check for the same from vGIC creation, and update the comments accordingly. Note, while KVM arm64 guards many vGIC operations with its arch-specific config_lock, holding kvm->lock is sufficient to guarantee a stable result for "is vCPU creation in-progress". So, no functional change intended. Note #2, the open coded check in vgic_init() is racy when called without kvm->lock held, e.g. via vgic_lazy_init(). I.e. that check needs to stay open coded to avoid triggering a lockdep assert. Whether or not the race is "fine" is a problem for a different day. Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) --- arch/arm64/kvm/vgic/vgic-init.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-ini= t.c index 4012df6002ea..a58575df36e9 100644 --- a/arch/arm64/kvm/vgic/vgic-init.c +++ b/arch/arm64/kvm/vgic/vgic-init.c @@ -97,6 +97,9 @@ int kvm_vgic_create(struct kvm *kvm, u32 type) /* * - Acquiring the vCPU mutex for every *online* vCPU to prevent * concurrent vCPU ioctls for vCPUs already visible to userspace. + * This also ensures KVM isn't in the middle of creating a vCPU, + * i.e. that there are no vCPUs that have been created but aren't + * yet fully online. */ ret =3D -EBUSY; if (kvm_trylock_all_vcpus(kvm)) @@ -105,18 +108,11 @@ int kvm_vgic_create(struct kvm *kvm, u32 type) /* * - Taking the config_lock which protects VGIC data structures such * as the per-vCPU arrays of private IRQs (SGIs, PPIs). - */ - mutex_lock(&kvm->arch.config_lock); - - /* - * - Bailing on the entire thing if a vCPU is in the middle of creation, - * dropped the kvm->lock, but hasn't reached kvm_arch_vcpu_create(). * * The whole combination of this guarantees that no vCPU can get into * KVM with a VGIC configuration inconsistent with the VM's VGIC. */ - if (kvm->created_vcpus !=3D atomic_read(&kvm->online_vcpus)) - goto out_unlock; + mutex_lock(&kvm->arch.config_lock); =20 if (irqchip_in_kernel(kvm)) { ret =3D -EEXIST; --=20 2.55.0.1082.g2b9226bbc0-goog From nobody Thu Sep 24 18:40:04 2026 Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) (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 D373D4EF134 for ; Mon, 21 Sep 2026 17:44:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.200 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012694; cv=none; b=GexpSE7z7V9JJXIfDEEsFSH3+wJUE1jEyxWPRQ9MasEVYVIZ5R/W4oKDTUGyKQHF5OIwDy2ypPpvoUd0vZ6LWLzqH01KnX7/yevZc6gwM1pAyxI69IP2S4D1nQ9mjhYu+3lDHv/xuytzD5gaW52ld9/Og49GwqqDNLdlkva2L2w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012694; c=relaxed/simple; bh=CNhibckm2761zC3hAPFvim0N4m7lGBRenE1P2zWSHJk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=m0xJdYv+vAJvxJyaGr15sjp9kuO66Kly/6kK0c4NX5V8Oy9LiA5xa9zVips1p0jkfT6nhsnXbnM8c7WWwep5S/uQe79yw5e02vKRxlnoN1huL9WYMEdb7qK+xh2ez+e6iO88WPXzQFg8C8GNodAuEcdoiS7Hiok1+LdUf0Rp73E= 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=Bb3voCAv; arc=none smtp.client-ip=209.85.215.200 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="Bb3voCAv" Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-cc21bc2923fso2938904a12.2 for ; Mon, 21 Sep 2026 10:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790012691; x=1790617491; 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=y4bAp3nBUO90ZQn1u2Z0gOxXpoxTWghtyWO5GBrBpXE=; b=Bb3voCAvMKzhwNJByrAcASRMJyiOXpR93gIZxKodAPUtwCo0aIyHa70Q35Ucc0nE4i iNmDPAiOtNcOav8gJOUfTfkrRTBn+/66Xg5JfZl9SqI0aPElHPQ5ok/mEjlqosh1CJo+ GLdI8aa2D4w6eBXvLcFFUZ1aSDUk0ra42I+qlvnBWAD+3qMK+EFmK5C4D7ao6CmTTl3z S8Q4bjzQE9M86aRsJow9qkOs7VW91RldTmMUkt03cJWn0IY4R2Do/heZ7l3eftXsBnZe PU3FnPar7xV9cUpbbAlph3EldG6iVaCpd8BrOL6Rc9MM/kG5TdGG4MeL7ZY66u1ikqJB 4VvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790012691; x=1790617491; 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=y4bAp3nBUO90ZQn1u2Z0gOxXpoxTWghtyWO5GBrBpXE=; b=PSCLvpTA4ld8K1n70JBzwI/aos7Uuag+iengSq23d7jDvkkZQDaR3e7GwPzo1wd4w6 YTvTLBibt7fZSDJ6G65sKKkczx/k1pHn7Tw3ArUrPculoAWXnKh5oPRbbdWUSCC/lMwR DYUPEuAYW88Xq2UVW6DI6xhvUzhPXpfilepZKaqrUpz1Roo9EDRfvrAQABR/AkfPA1pP v1OSfi9KcxUO3WvBeSPYvNzlceX/XdWx/Ydix2xiKBXShy0zhjIf/4kyAOyC027X4PTE cJ59DH1EokdX8Ij9DrATo2YKBnI8TgNJvNQpwHAHHMYEQG9H5ysuobm/l+NNDY586FVW yH1w== X-Forwarded-Encrypted: i=1; AKwUvByac2QyhUBZiUneH/cdrm9olbLvcR/g0TzP+I+Y662ezAgZrOTyLUfl+CzyHMWqKlR2ZvDEZeRtZ/47aJo=@vger.kernel.org X-Gm-Message-State: AFuF++lsl6BcxwFZkDWmsBQ2ArGx8W66Tk6J9MnoiwSBVGeZI0XDGAcE 1el+yDvN3ACtSXApYJeWtRHzz1INRMiptGgr2jwIl/zPfnrWQLEs5IrHiSp0sWeA5Vr5D+67qzL s7v/QZA== X-Received: from pgvn10.prod.google.com ([2002:a65:63ca:0:b0:cc4:5907:21e9]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:1b81:b0:3cd:8bba:824f with SMTP id adf61e73a8af0-3dd8c3d3acfmr19085095637.4.1790012690700; Mon, 21 Sep 2026 10:44:50 -0700 (PDT) Reply-To: Sean Christopherson Date: Mon, 21 Sep 2026 10:44:41 -0700 In-Reply-To: <20260921174445.911676-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260921174445.911676-1-seanjc@google.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog Message-ID: <20260921174445.911676-4-seanjc@google.com> Subject: [PATCH v2 3/7] KVM: RISC-V: Use kvm_is_vcpu_creation_in_progress() instead of open-coded equivalent From: Sean Christopherson To: Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sean Christopherson , Paolo Bonzini , Kiryl Shutsemau , Rick Edgecombe Cc: Nicholas Piggin , Atish Patra , Alexandre Ghiti , Dave Hansen , linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, Jean-Christophe Guillain , "=?UTF-8?q?Pawe=C5=82=20S?=" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use kvm_is_vcpu_creation_in_progress() instead of an open-coded equivalent during AIA initialization. Unlike similar vGIC code in arm64, the relevant RISC-V code runs under kvm->lock, i.e. can use the standard API without hitting lockdep false positive. No functional change intended. Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) --- arch/riscv/kvm/aia_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kvm/aia_device.c b/arch/riscv/kvm/aia_device.c index efc7c0bcfba9..97833a04268a 100644 --- a/arch/riscv/kvm/aia_device.c +++ b/arch/riscv/kvm/aia_device.c @@ -237,7 +237,7 @@ static int aia_init(struct kvm *kvm) return -EBUSY; =20 /* We might be in the middle of creating a VCPU? */ - if (kvm->created_vcpus !=3D atomic_read(&kvm->online_vcpus)) + if (kvm_is_vcpu_creation_in_progress(kvm)) return -EBUSY; =20 /* Number of sources should be less than or equals number of IDs */ --=20 2.55.0.1082.g2b9226bbc0-goog From nobody Thu Sep 24 18:40:04 2026 Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) (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 EF7E84EFFA7 for ; Mon, 21 Sep 2026 17:44:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.197 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012695; cv=none; b=QNjW5ccFL4zUVVDbpJSNSfUMIpeu0we6p+wsvR+BxZGtQa67cwBDjtaziLw+OLoCkaTCwP752TJTVccNd49beQbb4MYcyqftmUZ5Atocwkc2vF6ILNlWGwwkr+6DFchAyDmxssE5smuceXn+PLwQA0L5UCjsaHVV9047RJpbqLQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012695; c=relaxed/simple; bh=+jjHjwnLcMcNsDxPCbMB0oqiroo6BVNoCF+l0EJJBnw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ScpqoCbyusSFn8xYS8JPfFrOuS8A3rqNUOsU28C1YvF9cftuHxwirJNzP0QYiLwHvl/3yHQgB1uA29lJySAxnShx8Z41naATYL8jAADOCw5S3vpc6C3id5lb6P13LSD+QjV/kF5S2pctl5qcL2XYFrJEBNoR+DCtppu/CpIY/sQ= 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=rm3PuT63; arc=none smtp.client-ip=209.85.210.197 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="rm3PuT63" Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-855315ccb64so3193415b3a.3 for ; Mon, 21 Sep 2026 10:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790012692; x=1790617492; 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=qeiicXWgTPk3n7JADXXm7zikz8BknOrQz3jHJRoDF6U=; b=rm3PuT63S+dY+XPYFxDqxexEhVDCVqX1jgmMMclHxaJj/+V4RMvCntEhCshJ1RlIPe a5RsaUjONP6J/WStYdJsa85x0MO8TU4QOU51LEQJmdCDLf145UW6GNFfgQjooe/fzdpz RSmuq+Kb0HEI+z9fiS8H9uKy9hlagY1fftCcUx6YSBVrrVKhrvCtKIFG8fFTX+DHR9n1 4JcrUhDHtzc3juJSrNBtZK5isPIdkjnIpIM71LMlQNirOyO7pCXmS8uppbhqTaNUKD0v 9kPTZZja4CCqUy4cPcPDWoq0HpvDMWt4oLmvK2TJTmHczxQpCn5DIl6jVLdAGvcNDA/f BbXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790012692; x=1790617492; 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=qeiicXWgTPk3n7JADXXm7zikz8BknOrQz3jHJRoDF6U=; b=go0nxLwQpZCdyYDRebCHu6t+bPCJYvnq7ZFyjpvPw0lgZx0W2dDVgi1tlVy8kLAO43 MbyXIfdHBUoqR8h9gVxZfJgdm0hjV8sKVLZOdTX91bbE+Q+efzcyPve1pso11F4yQpw/ 0fU5ZoWYIevoLWCQSKNZkJ0bbtrnEe72oZlCrfcufkGyZ2/9fokfx6Zc0rEsYj8OW24w tqdhZOGkRC6YXLYEGXbHuicK6I1deuPQ+gKr5P5NcKs973hOdopBoDzBz5ehkuX1NHJB toQkWtJ0YbRsu1XNsfZKNIbJeO1ze9SIz3Y4Xfz6gKxJKJ+aew+q6doWNbLqJxcOPW1B sDrw== X-Forwarded-Encrypted: i=1; AKwUvBx093pnn3FxsukVUhKndyYqQN/PosZsEfiqZZ8j9LUxr6dRJ7nVdDfvJDPYXNkddpLDleSUP0fFynZT01Q=@vger.kernel.org X-Gm-Message-State: AFuF++l6n09xG/+Kk6TW2Sn2qg86epXEfoWy7GqI7uxI2qw8X9ZRESSz +8LmC1C1nlA59znKj19P3lcP3KGIE2t4oK26hinYW81kIQP3IZTPJ/IqT1a1/LnR2cCB/aER+rj Sk+9piQ== X-Received: from pfw3.prod.google.com ([2002:a05:6a00:a263:b0:879:1348:bebf]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1f06:b0:857:727c:a1f1 with SMTP id d2e1a72fcca58-874dddfa3acmr14506041b3a.19.1790012691865; Mon, 21 Sep 2026 10:44:51 -0700 (PDT) Reply-To: Sean Christopherson Date: Mon, 21 Sep 2026 10:44:42 -0700 In-Reply-To: <20260921174445.911676-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260921174445.911676-1-seanjc@google.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog Message-ID: <20260921174445.911676-5-seanjc@google.com> Subject: [PATCH v2 4/7] KVM: Protect all of kvm_vm_ioctl_create_vcpu() with kvm->lock From: Sean Christopherson To: Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sean Christopherson , Paolo Bonzini , Kiryl Shutsemau , Rick Edgecombe Cc: Nicholas Piggin , Atish Patra , Alexandre Ghiti , Dave Hansen , linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, Jean-Christophe Guillain , "=?UTF-8?q?Pawe=C5=82=20S?=" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When creating a vCPU, don't drop kvm->lock to when doing the bulk of actual vCPU creation, as allowing multiple vCPUs to be created in parallel adds significant complexity in KVM (as evidenced by the many related bugs), and all known VMMs fully serialize vCPU creation. Remove all manually locking of kvm->lock from kvm_arch_vcpu_{post,}create() for obvious reasons. For many years, "everyone" has assumed that dropping kvm->lock was done for performance reasons optimization, e.g. to allow userspace to create all vCPUs concurrently for latency purposes. But as above, no known VMM does that. Looking at the history of this code, before commit 11ec28047118 ("KVM: Convert vm lock to a mutex"), kvm->lock was a spinlock. I.e. KVM *had* to drop kvm->lock when doing the bulk of vCPU creation, otherwise KVM couldn't do normal memory allocations. When kvm->lock got turned into a mutex for unrelated reasons, no one took advantage updated of the change to simplify vCPU creation. And 19 years later, everyone just assumed that KVM continued to deal with the complexity for performance reasons. Furthermore, naively parallelizing vCPU creation in userspace is likely a net negative due to the overheads of task creation. Unless a VMM carefully avoids the extra overhead related to parallelization, e.g. spawns each vCPU's thread before creating the vCPU, creating vCPUs concurrently is a net *negative* up until about ~64 vCPUs, after which the times are a wash. The absolute speed of light _is_ faster if KVM doesn't hold kvm-lock, but at vCPU counts of ~16 or less, it's probably in the noise when considering total VM creation time, as the added latency is less than 1ms up until 16 or so vCPUs. On top of all that, KVM has had a *lot* of fatal bugs (most often found by syzkaller) related to vCPUs being created while trying to do per-VM operations (basically, see every flow that locks all vCPUs). I.e. the parallel vCPU creation "support" is actively harmful as the only "use case" is for misbehaving userspace to exploit KVM bugs. Serializing vCPU creation will allow reverting commit 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as possible"), which had "minor" math error: the worst case scenario isn't "256 bytes per VM", it's "256 unsigned longs per VM", i.e. 2048 bytes per VM, which doubles the size of each VM and pushes several architectures into order-1 allocations. Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) --- arch/powerpc/kvm/book3s_hv.c | 2 -- arch/s390/kvm/s390/s390.c | 5 +---- virt/kvm/kvm_main.c | 22 +++++----------------- 3 files changed, 6 insertions(+), 23 deletions(-) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index 0409ac9e7b31..30f7095a156e 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -3058,7 +3058,6 @@ static int kvmppc_core_vcpu_create_hv(struct kvm_vcpu= *vcpu) =20 init_waitqueue_head(&vcpu->arch.cpu_run); =20 - mutex_lock(&kvm->lock); vcore =3D NULL; err =3D -EINVAL; if (cpu_has_feature(CPU_FTR_ARCH_300)) { @@ -3091,7 +3090,6 @@ static int kvmppc_core_vcpu_create_hv(struct kvm_vcpu= *vcpu) mutex_unlock(&kvm->arch.mmu_setup_lock); } } - mutex_unlock(&kvm->lock); =20 if (!vcore) return err; diff --git a/arch/s390/kvm/s390/s390.c b/arch/s390/kvm/s390/s390.c index eca4a4359ab2..cc628afbb850 100644 --- a/arch/s390/kvm/s390/s390.c +++ b/arch/s390/kvm/s390/s390.c @@ -3579,12 +3579,11 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu) =20 void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu) { - mutex_lock(&vcpu->kvm->lock); preempt_disable(); vcpu->arch.sie_block->epoch =3D vcpu->kvm->arch.epoch; vcpu->arch.sie_block->epdx =3D vcpu->kvm->arch.epdx; preempt_enable(); - mutex_unlock(&vcpu->kvm->lock); + if (!kvm_is_ucontrol(vcpu->kvm)) { vcpu->arch.gmap =3D vcpu->kvm->arch.gmap; sca_add_vcpu(vcpu); @@ -3757,13 +3756,11 @@ static int kvm_s390_vcpu_setup(struct kvm_vcpu *vcp= u) =20 kvm_s390_vcpu_pci_setup(vcpu); =20 - mutex_lock(&vcpu->kvm->lock); if (kvm_s390_pv_is_protected(vcpu->kvm)) { rc =3D kvm_s390_pv_create_cpu(vcpu, &uvrc, &uvrrc); if (rc) kvm_s390_vcpu_unsetup_cmma(vcpu); } - mutex_unlock(&vcpu->kvm->lock); =20 return rc; } diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 78cc090435be..c17cc8dd371b 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -4165,6 +4165,8 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, = unsigned long id) struct kvm_vcpu *vcpu; struct page *page; =20 + guard(mutex)(&kvm->lock); + /* * KVM tracks vCPU IDs as 'int', be kind to userspace and reject * too-large values instead of silently truncating. @@ -4177,26 +4179,18 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm= , unsigned long id) if (id >=3D KVM_MAX_VCPU_IDS) return -EINVAL; =20 - mutex_lock(&kvm->lock); - if (kvm->created_vcpus >=3D kvm->max_vcpus) { - mutex_unlock(&kvm->lock); + if (kvm->created_vcpus >=3D kvm->max_vcpus) return -EINVAL; - } =20 - if (test_bit(id, kvm->vcpu_ids)) { - mutex_unlock(&kvm->lock); + if (test_bit(id, kvm->vcpu_ids)) return -EEXIST; - } =20 r =3D kvm_arch_vcpu_precreate(kvm, id); - if (r) { - mutex_unlock(&kvm->lock); + if (r) return r; - } =20 kvm->created_vcpus++; __set_bit(id, kvm->vcpu_ids); - mutex_unlock(&kvm->lock); =20 vcpu =3D kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL_ACCOUNT); if (!vcpu) { @@ -4227,8 +4221,6 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, = unsigned long id) goto arch_vcpu_destroy; } =20 - mutex_lock(&kvm->lock); - if (WARN_ON_ONCE(kvm_get_vcpu_by_id(kvm, id))) { r =3D -EEXIST; goto unlock_vcpu_destroy; @@ -4267,7 +4259,6 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, = unsigned long id) atomic_inc(&kvm->online_vcpus); mutex_unlock(&vcpu->mutex); =20 - mutex_unlock(&kvm->lock); kvm_arch_vcpu_postcreate(vcpu); kvm_create_vcpu_debugfs(vcpu); return r; @@ -4278,7 +4269,6 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, = unsigned long id) xa_erase(&kvm->vcpu_array, vcpu->vcpu_idx); unlock_vcpu_destroy: vcpu->vcpu_idx =3D -1; - mutex_unlock(&kvm->lock); kvm_dirty_ring_free(&vcpu->dirty_ring); arch_vcpu_destroy: kvm_arch_vcpu_destroy(vcpu); @@ -4287,10 +4277,8 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm,= unsigned long id) vcpu_free: kmem_cache_free(kvm_vcpu_cache, vcpu); vcpu_decrement: - mutex_lock(&kvm->lock); kvm->created_vcpus--; __clear_bit(id, kvm->vcpu_ids); - mutex_unlock(&kvm->lock); return r; } =20 --=20 2.55.0.1082.g2b9226bbc0-goog From nobody Thu Sep 24 18:40:04 2026 Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) (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 6E4894EDCCF for ; Mon, 21 Sep 2026 17:44:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.198 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012696; cv=none; b=uO1avVdG9nxi8rEXx/zay1hItwdF8s6/WJ0a6zIjiIVdsHJQksyc9OIyvHGQCCOzhUiRIvEyc48uSRgHYQ2XFNgWFjdR4i+kLHBZvKYdlS1I4t49SFaR4/jO07bxTR1otZ36kNkOrjta/9IUsPC4UpsLBcyOnSSDXR4vShsOGss= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012696; c=relaxed/simple; bh=ZDfXvDacTET7r9tcukRk54MywQ4no29qxUUGATskm7w=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Q943NAllL7ByJRjMotY/Rc/vih4b63riOhVANHp4wBjHY87c5rycocvYujK3bFZALff+Z7AX5GZl1kn4GBdrwJkN2/uSyfXpv9CYpE1SVJL21aJFLLy5Yl6wTFxsL9MTnWNzWv+HtqLF4gaqUFnH5tzXv0cxIThgwCp5NP0jQEc= 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=LXiMJw6A; arc=none smtp.client-ip=209.85.215.198 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="LXiMJw6A" Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-cc44d708055so517072a12.0 for ; Mon, 21 Sep 2026 10:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790012693; x=1790617493; 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=QYiGmxrgAXU1trJ4S0lv2S3WvlXO7vDS7xlQ1HDVynU=; b=LXiMJw6A8Tzz/1EryXmvX+JnXBUSozVDbj5asA1QESKMdDoASTeNze+wxAezArHvqz kYBmtNabltlxMt9+q/NplqVUO2kGRM4yLLqbrTw3XI88sVa8xJ3pJl60yHvqfF0ZGLs4 k3+k6S1WCNwA7pVplxIaX9cP2Q/TDDX6HfW3ztz9BMT6Cd5o4/IzdMTjlb3cSn+jnDTJ tbQgs7k5o5TGV0x1lsZjOWSgQjOIWCVqPXjohRRGdpxGv5PLRsOAD1+pGy7iojk7ped8 qNxqGomWN4ghDirIraF/Eo/Gh4ZGBtoZnlpx4NTJXVzsiuwSBFOOBjJkLlcCGU107klp rRPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790012693; x=1790617493; 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=QYiGmxrgAXU1trJ4S0lv2S3WvlXO7vDS7xlQ1HDVynU=; b=TdrTEeyCh4jA74L35sS2HSDS6zMnJfMu4P8jFz0358hOG+qVncJaN7RYLT45OByUBR vRccj/mhY+rAFOxrLnQKsvVlMMGigh3Nc1RgdkvprEh7xnNkqul0Xkqz1aOX+F1zZOET pqhR3eY6MV2vkhWbktSTNdM/T1umJC+awPvV8GUR28COOny4OAjplvfdocNj/sKXoBLP mQTon5dO6n1nNbKj3tzklaYWtH8A4UecW/OFamJZEszksPQslcBqhq5a/F1A9xiMw1TE TPR1Hb9ANrwI+XR4pPo1AcmR6rfhJ4ANpVi6TB6NDuhX8PijZM3IbnXPQYhxe5hoDZK0 vLPQ== X-Forwarded-Encrypted: i=1; AKwUvBzBpGJ1eJSP2XtrjmLBUzu/mcJClxwTngNKfwyXfWtYQKhB7DJI9obntbayEzhV+Yn8rnMmzrQIms4aIFk=@vger.kernel.org X-Gm-Message-State: AFuF++mO/mHgHaiMbdwrbWam3GGGmmt305DNprxBPxSruEnJ3z4Cl8DP ifOO7ybBm3ra8uw4mPItaskv63HujUCdmS+GMwnDeoatLL3jZqkDJ9zEqgVQK6UiU+56OcDhtUz p8PRFVQ== X-Received: from pfbhu19.prod.google.com ([2002:a05:6a00:6993:b0:879:55dd:922d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:ad89:b0:85f:3d78:79cc with SMTP id d2e1a72fcca58-874dc4ed21dmr15528120b3a.9.1790012693049; Mon, 21 Sep 2026 10:44:53 -0700 (PDT) Reply-To: Sean Christopherson Date: Mon, 21 Sep 2026 10:44:43 -0700 In-Reply-To: <20260921174445.911676-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260921174445.911676-1-seanjc@google.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog Message-ID: <20260921174445.911676-6-seanjc@google.com> Subject: [PATCH v2 5/7] KVM: Move check for existing vCPU ID to the top of vCPU creation From: Sean Christopherson To: Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sean Christopherson , Paolo Bonzini , Kiryl Shutsemau , Rick Edgecombe Cc: Nicholas Piggin , Atish Patra , Alexandre Ghiti , Dave Hansen , linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, Jean-Christophe Guillain , "=?UTF-8?q?Pawe=C5=82=20S?=" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Now that kvm->lock is held for the entirety of vCPU creation, check for a conflicting vCPU ID at the begnning of vCPU creation, before the arch precreate() hook is invoked. This will allow reverting commit 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as possible"). For now, keep the redundant vcpu_ids tracking as a sanity check. No functional change intended (absent KVM bugs, checking vcpu_ids and walking kvm_get_vcpu_by_id() should yield the same result). Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) --- virt/kvm/kvm_main.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index c17cc8dd371b..d5524ac8c5cf 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -4182,7 +4182,10 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm,= unsigned long id) if (kvm->created_vcpus >=3D kvm->max_vcpus) return -EINVAL; =20 - if (test_bit(id, kvm->vcpu_ids)) + if (kvm_get_vcpu_by_id(kvm, id)) + return -EEXIST; + + if (WARN_ON_ONCE(test_bit(id, kvm->vcpu_ids))) return -EEXIST; =20 r =3D kvm_arch_vcpu_precreate(kvm, id); @@ -4221,11 +4224,6 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm,= unsigned long id) goto arch_vcpu_destroy; } =20 - if (WARN_ON_ONCE(kvm_get_vcpu_by_id(kvm, id))) { - r =3D -EEXIST; - goto unlock_vcpu_destroy; - } - /* * Set the vCPU's index *before* the vCPU is reachable by other tasks. * Unwind the index back to -1 on failure so that KVM can use the index --=20 2.55.0.1082.g2b9226bbc0-goog From nobody Thu Sep 24 18:40:04 2026 Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) (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 1543A4F3911 for ; Mon, 21 Sep 2026 17:44:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.197 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012698; cv=none; b=RO8pU09zS2+vuOfMCSzBgdZINypqiqMLSSkczUnc2WbIn91KgASiOLltHGchu3v2NE+3LBbsW+JTQp1aXysQ/YH8Wurqyi5opWulVtpgjXctyArGpI7M7gzV9q2HPci7ZSd8cjkv23yd0puuAU7hf7/pGJS+VzDEWxQBG90Kwu8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012698; c=relaxed/simple; bh=d+HwDcZ+iWoQ8qx4aIkqNrZBIcx5nx1EjGGCYbcSOIk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=qOoJR5UOK8j9dpku4J3s+j6WT7/VUlqoeymIB4U341FVPc+XlsX9WUElMwEsYMR1MkX+j8rw7ybTp97o3fJLsC/ZgfKsKw92FV9hFNDqF42kIxS2bkFH5rWrbY4qZEH4IsLf8ABRn1OKlBUWXe4unXA8GPtLMdEXQUuk6O/rMlM= 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=MjK+Lhbz; arc=none smtp.client-ip=209.85.214.197 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="MjK+Lhbz" Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2d55d8cd938so57262495ad.1 for ; Mon, 21 Sep 2026 10:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790012695; x=1790617495; darn=vger.kernel.org; h=content-transfer-encoding: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=P1dhUTiarEg5c5I3QHkxBctKjtcsAKr4VX6TAcrbU/Q=; b=MjK+Lhbz6n9fDdU1YnwTwiUovGBjcBtBF4cjiFbty9KkqIQW9WipbRFKvMZU2jx8Wz uOu8KE4fNOSEyRgML8JSsPEZ1494PBkA8bvIlg0SCyRJ7F0SJYX89b/HTqc5OpLoVXQe VrCJpv2Fet+xuF6U9WV9Or+dAn1MU8hANnHnfytV0X4j828Fb41j6kJqMp+mkkkTwLEM JlFwKaqPosXSOa+FXusqLWr9KPK/rpw6ScmYEl55erPPw0HMQbkZlI/K39mRkmkz441q U/feM855rqMhcz88n378fTwCZb09s7M7ew072ZHImbkALSTWliWjn7EtlZgnnY1kjuVi KFcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790012695; x=1790617495; h=content-transfer-encoding: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=P1dhUTiarEg5c5I3QHkxBctKjtcsAKr4VX6TAcrbU/Q=; b=MXXKVJH6/CnzhTt3cRZQdLAsGbwpS8R8DJmDChpUmgAIy3cZeC6ixU4BbzqGR3WWVW HNmVBMnkYVRjeSz4bLOz2kAS20GNMs0NetJcHQcpVvzbTFpmY3fnH/Pj2WLkBAi9kTYC 0Ennc9/GmQjAIMBX7YUzs0XNt2sXrpJ4ONGdCUNnwxv9/z036+TNt13uG5j3bNIkcCqR q1j3D28Sqs7n6FxpkCu90r0ptd8LoOS3DbroI3stse9jnGBVy1iQCyLTvQJuSViP6eER lqKw9O3cJMw180Q0Z3ChGpCAavZsfpWyb6XWitPIMzY1ooVIXZzavEAIw+hxZdLSLCui a8fQ== X-Forwarded-Encrypted: i=1; AKwUvBwfSwLBZxJ+PSTPTi0jD31+pvK/TgNEM3lFcqjYN932KLxeCnjjJkG9zgUOu58wDGrkkmpVGFeMv5Z6Qds=@vger.kernel.org X-Gm-Message-State: AFuF++kWs0XyGfKYqoAgfCfFA01nOuHMiEAQVDz1+G7O40RIgh2+B9bO TVS3ikGyqtMWUJ/YPqfS32qlxyUImaNQeithUNb3CfBlLKLjnbAneiaXnFR1Ws6z+K1k+PcMAPu 1gjDVAQ== X-Received: from plao21.prod.google.com ([2002:a17:903:3015:b0:2dc:5417:2772]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:d984:b0:2df:3b09:664 with SMTP id d9443c01a7336-2df3b0909cbmr71040325ad.32.1790012694298; Mon, 21 Sep 2026 10:44:54 -0700 (PDT) Reply-To: Sean Christopherson Date: Mon, 21 Sep 2026 10:44:44 -0700 In-Reply-To: <20260921174445.911676-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260921174445.911676-1-seanjc@google.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog Message-ID: <20260921174445.911676-7-seanjc@google.com> Subject: [PATCH v2 6/7] Revert "KVM: Check for duplicate vcpu_id as early as possible" From: Sean Christopherson To: Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sean Christopherson , Paolo Bonzini , Kiryl Shutsemau , Rick Edgecombe Cc: Nicholas Piggin , Atish Patra , Alexandre Ghiti , Dave Hansen , linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, Jean-Christophe Guillain , "=?UTF-8?q?Pawe=C5=82=20S?=" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Now that KVM uses kvm_get_vcpu_by_id() to check for an existing vCPU ID before doing any meaningful work, which was made possible by holding kvm->lock for the entirety of vCPU creation, revert the now-redundant "early" vCPU ID tracking. The claims about the impact of kvm->vcpu_ids on the memory footprint were a wee bit wrong: the worst case scenario isn't 256 bytes per VM, it's 256 "unsigned longs" per VM, i.e. 2048 bytes per VM. Increasing the size of "struct kvm" by 2048 nearly doubled the total size on many architectures, and tripped x86's KVM_SANITY_CHECK_VM_STRUCT_SIZE, which was added to detect this *exact* scenario, where a single change significantly increased the size of "struct kvm". I.e. attempting to build KVM with CONFIG_DEBUG_KERNEL=3Dn fails on x86 (the build failures got missed because all build bots apparently test only CONFIG_DEBUG_KERNEL=3Dy kernels, and maintainers' test flows were similarly lacking). This reverts commit 97d65b544f48b2ee49f6aea32145e3e7969955dc. Fixes: 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as possible= ") Reported-by: Jean-Christophe Guillain Closes: https://lore.kernel.org/all/56a4bc35ee605588b7cc36c8e45c12b5f3b506c= b.camel@guillain.net Reported-by: Pawe=C5=82 S Closes: https://lore.kernel.org/all/CABD%3DWFOS4j4hDv%2BpW-eEM9HAM2q2GY_iYd= AG%2BqvYcUEinUrcQQ@mail.gmail.com Tested-by: Jean-Christophe Guillain Signed-off-by: Sean Christopherson Tested-by: Naveen N Rao (AMD) --- include/linux/kvm_host.h | 1 - virt/kvm/kvm_main.c | 5 ----- 2 files changed, 6 deletions(-) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 03bfc92864b6..6aab167bf482 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -791,7 +791,6 @@ struct kvm { /* The current active memslot set for each address space */ struct kvm_memslots __rcu *memslots[KVM_MAX_NR_ADDRESS_SPACES]; struct xarray vcpu_array; - DECLARE_BITMAP(vcpu_ids, KVM_MAX_VCPU_IDS); /* * Protected by slots_lock, but can be read outside if an * incorrect answer is acceptable. diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index d5524ac8c5cf..985af39b980a 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -4185,15 +4185,11 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm= , unsigned long id) if (kvm_get_vcpu_by_id(kvm, id)) return -EEXIST; =20 - if (WARN_ON_ONCE(test_bit(id, kvm->vcpu_ids))) - return -EEXIST; - r =3D kvm_arch_vcpu_precreate(kvm, id); if (r) return r; =20 kvm->created_vcpus++; - __set_bit(id, kvm->vcpu_ids); =20 vcpu =3D kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL_ACCOUNT); if (!vcpu) { @@ -4276,7 +4272,6 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, = unsigned long id) kmem_cache_free(kvm_vcpu_cache, vcpu); vcpu_decrement: kvm->created_vcpus--; - __clear_bit(id, kvm->vcpu_ids); return r; } =20 --=20 2.55.0.1082.g2b9226bbc0-goog From nobody Thu Sep 24 18:40:04 2026 Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) (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 DE4664EDCDF for ; Mon, 21 Sep 2026 17:44:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.71 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012700; cv=none; b=aBwLJwUssdphBRFvC3g7ZmPW9AbkaPLJcO6jRergVh4MmitBhr9hiP2dKrJqOjTN2DikZWGuhIh238qSCNTknfINJ8xu71/3m6CX1DcVYxlrz2LlS5ZIHDYirLhELgys4ZhFx2kzw4o+y1zsACCbjK8+gCvcyFDJ50kHVMMvq0U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790012700; c=relaxed/simple; bh=cYA9lzFyBuFHQr7HU3AfB1/Agrqq855in7GcwhtndPs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=S+oSEjvpJVZwlTrFpXHtiljldHT9XD2WasA0E5Ie9R6iLizmKyop2aAc9gJuf0NMzLq+NhasMRhP/5W8dtAWEOckUPiUsI+Mj4xydGdxI2Z8oGYu0rfpbUMOQKMcNE2WLnHzH8/xrNqKgzOJlLEkqVUUsmfHZURgKMVYjLSNaxU= 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=vTTI1jS8; arc=none smtp.client-ip=209.85.216.71 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="vTTI1jS8" Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-39b77130a7fso5892721a91.2 for ; Mon, 21 Sep 2026 10:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790012696; x=1790617496; 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=YYqX0VJzWkRuy7Rww/xIfxaxsSEw1uv9+hGx8/FiNWw=; b=vTTI1jS8DXCi3X0tO7uOey2f0A9w3S6ONo3tdTCYkPVFtZx6ozR2NbGGh6qt7pzs9a DYTuMR71i2jDR1tiTcIZliLA+Ysz9XNPKRq3HKRMAeZjKGazHQomsOnFlhNwdb+DqtPC aOHwsTfVhdQSKzoOtM4MDVsGGwLJuAgybR446TbPvurb4SA1ROv3LnGB087ass98Nd7T vtf8D+JgsB/ul2aDhPfSIsWu/kmj6pKDhczCFu84kMgrZboOwDBj5Rk9OTdt+jCDF+4k Wl0trL5MgmOEjBO3by2Bg+IsxV6B5HTtzI6Wo3N4v0MeNqw69nHGJjWnqsvcCOFWl0pC WuGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790012696; x=1790617496; 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=YYqX0VJzWkRuy7Rww/xIfxaxsSEw1uv9+hGx8/FiNWw=; b=Acwe/34u1373urCtdpptkdM1BJfagyOijfcL954+B/bT4sNMpFFuuTysB0wRhb3NIL EhhqNY63cHRQIBZCTe6r00iC9yrc4R3Jcc5eh+E80sBZLS7wXo7Fe5Rz9+rdQgx/U/YZ FYS1KKH4u2g5Rsz2h4zKavtjxFmW++ec9eMuIx+X+0tqf9XW+5HEDaGgP0aZ2cx004Xu 1b6amueqVT44aQ9i0f9fVFpJcFBTRXwjIyKOT6zL60TXHRBRno+FUyHGUrx4hh0W2AbX +062x11BTarWvBZXRUYqdLIf0sHOWCUdWyyzaxaPONIrD8KqjQncZlLrQHs4QcycNQmU WzCw== X-Forwarded-Encrypted: i=1; AKwUvBxAJKldTbOgOBIuL6APWEJd8YrAO5YeDClh38pY7qinyb88FkeOE91MVhKk1vAqQX4EDsCWfMZkItBSWCg=@vger.kernel.org X-Gm-Message-State: AFuF++nz7/2mr4R/tS+wtFz7j4FW0ScnT4HeDWvf3xsCuYOX8woj5j2c tZAGaDZQx76zQbZ4p2WaZhGryWP+hibLkwvO5gm4mpqHHF2y7tiDYtYNwjWqbuYPYdYARBZE9RD bW0Eoug== X-Received: from pjro5.prod.google.com ([2002:a17:90a:b885:b0:3a0:645b:1c57]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:d888:b0:39e:4c7f:8b16 with SMTP id 98e67ed59e1d1-39e54cf8bdbmr17922638a91.27.1790012695572; Mon, 21 Sep 2026 10:44:55 -0700 (PDT) Reply-To: Sean Christopherson Date: Mon, 21 Sep 2026 10:44:45 -0700 In-Reply-To: <20260921174445.911676-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260921174445.911676-1-seanjc@google.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog Message-ID: <20260921174445.911676-8-seanjc@google.com> Subject: [PATCH v2 7/7] KVM: WARN if vCPU creation is in-progress when locking all vCPUs From: Sean Christopherson To: Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sean Christopherson , Paolo Bonzini , Kiryl Shutsemau , Rick Edgecombe Cc: Nicholas Piggin , Atish Patra , Alexandre Ghiti , Dave Hansen , linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, Jean-Christophe Guillain , "=?UTF-8?q?Pawe=C5=82=20S?=" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Now that KVM holds kvm->lock for the entirety of vCPU creation, from when created_vcpus is incremented until the new vCPU is fully onlined, WARN if the impossible happens and KVM somehow sees a discrepancy between the number of vCPUs "created" and "onlined". Signed-off-by: Sean Christopherson Tested-by: Jean-Christophe Guillain Tested-by: Naveen N Rao (AMD) --- virt/kvm/kvm_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 985af39b980a..e66d9761ee49 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1363,7 +1363,7 @@ int kvm_trylock_all_vcpus(struct kvm *kvm) =20 lockdep_assert_held(&kvm->lock); =20 - if (kvm_is_vcpu_creation_in_progress(kvm)) + if (WARN_ON_ONCE(kvm_is_vcpu_creation_in_progress(kvm))) return -EBUSY; =20 kvm_for_each_vcpu(i, vcpu, kvm) @@ -1389,7 +1389,7 @@ int kvm_lock_all_vcpus(struct kvm *kvm) =20 lockdep_assert_held(&kvm->lock); =20 - if (kvm_is_vcpu_creation_in_progress(kvm)) + if (WARN_ON_ONCE(kvm_is_vcpu_creation_in_progress(kvm))) return -EBUSY; =20 kvm_for_each_vcpu(i, vcpu, kvm) { --=20 2.55.0.1082.g2b9226bbc0-goog