From nobody Mon Apr 6 16:12:46 2026 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.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 12D5C426686 for ; Mon, 2 Mar 2026 17:02:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772470964; cv=none; b=M5+6CPIHyuVfty7bd+A/IwpyLph1JVGqKQjaFNMPhIlP2kfGJdR+nmnaTi1LoCraOzkM+NIT8iSKwC4lRJ+L7DeCHBHWjdHsoFYhA7hIWRKJpsJXjJgH94CRbtbT5h5lWl+UaUIvrVtEKPGAS8ed0kAw/44rT8wSRt+msTcUePQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772470964; c=relaxed/simple; bh=f7f6RNaV0yL3M61YiC7jd5CCIvUd17Z5NSWa/2LOMhg=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=Knk9nEYKlQzzoDQrYFfrf5rsVVOv8EgKXt/qhBi+pDwgG/4FOgHTPgRv+v0oiHBbtu8hYI05NjoP1uDtr+LGKRaMPus5OXB4pRjOsC4wL2MQdjhsBK4Yiu5CRn40wAJ4DmVYbilrK+ERflvaZM2BCeki0COldjlDlZswgGM5vYM= 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=T1FIhc6F; arc=none smtp.client-ip=209.85.215.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="T1FIhc6F" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c70ea91bfe1so3015847a12.1 for ; Mon, 02 Mar 2026 09:02:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772470962; x=1773075762; 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=D7nIJKnAoTlZY5dkO0+xgnDvgGoKc3sJhm52pQfwJ7k=; b=T1FIhc6F8MXdZikqypWZJAlmBBUGA/YLvfF0axgVD/DQkwzweQjvmFwRcNxsDyzuR/ TMYIcgj/lqGYSvnMNHQte7uKGNFqVWckWexF4OtE6XnNO+zNc1p7IZQIjnZe/3DS+TYY R78xAMio1GS+iqsFVMLUPGWwTjGJVCINnPH4IS9YwwBs+hpThO7zR+ktYbvOA7DOJwrz iEDQDhFQisbrAo102Y7sHmbFE3m/VxtQL1zeQHxBAjipl8ksugOAsoHVUjKhbsImEAXz rOkn2WXef+5OCWTFxqBFTO08cVunbPcPkgMSWEbLvDJUHcsDsjSTVlrCayDEhNCyngOO Fgjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772470962; x=1773075762; 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=D7nIJKnAoTlZY5dkO0+xgnDvgGoKc3sJhm52pQfwJ7k=; b=mydvYxhV3CkvSch0d138GJRmsc1VFMIrXKcNutzNg000v+Jz97kcQGn8HAORHgD7Xz 5Jtpy58FQZoLlaMIpjcRSTwu/E0WF6ZMbZEQAQZoO8nIWFf3+vmBz1/SsJwjGuFa9/ZE ZffRENAE6RIGTE8uI/R94RwAlbj4bHPh/fdbRnZH1XWqTQd045o9HRcwUHPNHxHY36x7 Kh519Fd5KbleQCNUrnxQ5+o32UtLxPYeTzO9RogNHP0vBDocEOkn1orXQTkzzd7L2lMm GoPaRo69d+2w5v9cDxDY2dAyQs8xSds/zM4BenpEN0pyorN1uHHM/1aUEU9LMUgT3LHb tQ5g== X-Forwarded-Encrypted: i=1; AJvYcCWtfGZZ8/K0VrR30w5bWvjRWceQCJsWO2oFY4MBaWL8qGvPdEvKeGloAdTjnIvb9Rnva2Qf2zujExDUuj4=@vger.kernel.org X-Gm-Message-State: AOJu0Yw2txJvwFrRGxMnnFKxxkoubDga3U1G3xxqzYZSb8FQbnPSSHWH up6Oa6Op0aPDt5ku2PcQzCkZOj9++GIIiDNo+5Ke0wWmyB4C8niBGqwf3uVaTeGhiqLiEc6pz1O cuSEJaA== X-Received: from pjyl18.prod.google.com ([2002:a17:90a:ec12:b0:359:8830:eace]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:c106:b0:356:35a5:4a64 with SMTP id 98e67ed59e1d1-35965c17f3cmr11375810a91.4.1772470962136; Mon, 02 Mar 2026 09:02:42 -0800 (PST) Reply-To: Sean Christopherson Date: Mon, 2 Mar 2026 09:02:39 -0800 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.53.0.473.g4a7958ca14-goog Message-ID: <20260302170239.596810-1-seanjc@google.com> Subject: [PATCH v2] Documentation: KVM: Formalizing taking vcpu->mutex *outside* of kvm->slots_lock From: Sean Christopherson To: Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Oliver Upton , Marc Zyngier , Sean Christopherson Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Explicitly document the ordering of vcpu->mutex being taken *outside* of kvm->slots_lock. While somewhat unintuitive since vCPUs conceptually have narrower scope than VMs, the scope of the owning object (vCPU versus VM) doesn't automatically carry over to the lock. In this case, vcpu->mutex has far broader scope than kvm->slots_lock. As Paolo put it, it's a "don't worry about multiple ioctls at the same time" mutex that's intended to be taken at the outer edges of KVM. More importantly, arm64 and x86 have gained flows that take kvm->slots_lock inside of vcpu->mutex. x86's kvm_inhibit_apic_access_page() is particularly nasty, as slots_lock is taken quite deep within KVM_RUN, i.e. simply swapping the ordering isn't an option. Commit to the vcpu->mutex =3D> kvm->slots_lock ordering, as vcpu->mutex really is intended to be a "top-level" lock, whereas kvm->slots_lock is "just" a helper lock. Opportunistically document that vcpu->mutex is also taken outside of slots_arch_lock, e.g. when allocating shadow roots on x86 (which is the entire reason slots_arch_lock exists, as shadow roots must be allocated while holding kvm->srcu) kvm_mmu_new_pgd() | -> kvm_mmu_reload() | -> kvm_mmu_load() | -> mmu_alloc_shadow_roots() | -> mmu_first_shadow_root_alloc() but also when manipulating memslots in vCPU context, e.g. when inhibiting the APIC-access page via the aforementioned kvm_inhibit_apic_access_page() kvm_inhibit_apic_access_page() | -> __x86_set_memory_region() | -> kvm_set_internal_memslot() | -> kvm_set_memory_region() | -> kvm_set_memslot() Cc: Oliver Upton Cc: Marc Zyngier Signed-off-by: Sean Christopherson --- v2: - Document that vcpu->mutex is taken outside of slots_arch_lock. [Paolo] - Rework changelog to not claim that taking vcpu->mutex outside of slots_lock is "arguably wrong". [Paolo] - Provide sample call chains for slots_arch_lock. [Paolo] v1: - https://lore.kernel.org/all/20251016235538.171962-1-seanjc@google.com - https://lore.kernel.org/all/20260207041011.913471-3-seanjc@google.com Documentation/virt/kvm/locking.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/lo= cking.rst index ae8bce7fecbe..662231e958a0 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -17,6 +17,8 @@ The acquisition orders for mutexes are as follows: =20 - kvm->lock is taken outside kvm->slots_lock and kvm->irq_lock =20 +- vcpu->mutex is taken outside kvm->slots_lock and kvm->slots_arch_lock + - kvm->slots_lock is taken outside kvm->irq_lock, though acquiring them together is quite rare. =20 base-commit: b1195183ed42f1522fae3fe44ebee3af437aa000 --=20 2.53.0.473.g4a7958ca14-goog