From nobody Thu Feb 12 19:05:42 2026 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 8D4AEA31 for ; Sat, 8 Jun 2024 00:06:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805207; cv=none; b=TfH3vdAuuB2+UXQMRxwNkR6uZY+M3gWoV092MfUpkNpnFUFxhKUH9wG5VjeyBik53J9stPAsGDeIQw4EKPYHSBy1/wbLsKErKYf12N+eZRtJpl0va778wTY1rykcsG+FixuX2qSKqf1MygaJc4lGQqtIHOLYwciTGY5SZwTTouA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805207; c=relaxed/simple; bh=qJZbgpT2J4Q/YFaFhTfRoIrKqervtsXgKC3zR+tLw5s=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=NsrwfnHhOaKFGLJNwk6sFw7cZbDgJ+JJNK8K6eNorRIdYmtTHbaqvMQyl5PjDkirgpUfNnm5U00X3b/nwjkW8z+QAcYjmiJbV2QvgKIkJR6+Dq2g/zpLtJFVm5t3d+VYiaJC/TKIRVT+ocGHVq3wmBHmt1Wj+pfPAmGaNFsoZ9k= 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=GedBEcew; arc=none smtp.client-ip=209.85.214.202 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="GedBEcew" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-1f68c07cbbeso19340935ad.3 for ; Fri, 07 Jun 2024 17:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717805204; x=1718410004; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=iq6DmtHz6SSF9fb08PX7PUoTv1+Fjd4jsK+/PHHPXto=; b=GedBEcewHodC7XdXHcWYt+kP49pkS6EW5EXw4wp/ZoE8OtxTv+ZfWPNiRZrRcABdF2 zy9VA6JCN/6vVbcLHbnRVHKhQROTRN4GmWAd+kDkKUXpieS7qnnHO5MqiPZuyhXMICeR gRtB9dRVuHeK/deMXqQneaTkvCReWVv2zCzeIwepVmBqxOAYuthWlx0s1yBRnf+HLoTE DH86ILMs2Fy/qg/nfuT2CjqYt/ChTI1deHQbKILK9Nilx6kccRJgR1l+lXytYTTE7T5X Rk5jAqdw3F8vLBFJbqLOv+JIaX54k37wg/SWrqzgl+bmjVPnXuodwkRi+bp42WNm9nJM fVCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717805204; x=1718410004; h=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; bh=iq6DmtHz6SSF9fb08PX7PUoTv1+Fjd4jsK+/PHHPXto=; b=RGL4JTGdWHp9XbvCjCJzvLvvTRMl3rK2S1WHfekafReEl8kFXHAgzpH6GL3ijWt7Kc I9M0lcl3nuYi/x1NZy7zV4XXgjdlKhzDknrQDRidLspOwHka4fXW4n9zY6nL/bRUoeNp GPRtlEjgDFG0g6C5UoDbtHSo7bM1ebUTennJTVL9dOLQYEZCxw2YVwjdTWEj7eJqwvfN MMAbZJC4LcceLF7glvq99Y2nqz+CckBnEC8LcSTelKwyp0Ux9wioSw8NEgh+NXtXYyH+ 8CWp5Egz0Gkmdp+wHiy9L38wBZ5IgJPSztUWIO5GGJaITpOsv9Xd2ekGc8KwTklxm4Wb dViw== X-Forwarded-Encrypted: i=1; AJvYcCUBIom2Ez0zynKHcsgG+9lZUN26FOWDwbBz+yLvOcSrirW/CLqlXUFmg8OF+sSXMKhidQJlLgjElUD6H2vbZcXC50m/R/E2HUbtsYRP X-Gm-Message-State: AOJu0Yy9ARhlhI7k1D4tTGV/5i0kjqD020LiLavCwUBTzI4OQi/kLXS9 xq2ZaoaBYe/hHbxreAK+ZAQgcRvXnZg23G4n90F2JLVBMaQPbG8gzbnnpOR5Y/yc4M89ksuQciX 6SQ== X-Google-Smtp-Source: AGHT+IFX7XA1z/r7DTD+xg8pBAk2Ziz2yxBNYPknTvwUeL/gY7i62oOk8PrbJK11m2b86KyxJqzu59I5xl4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:aa8a:b0:1f6:565f:27af with SMTP id d9443c01a7336-1f6d03b81d4mr1419915ad.12.1717805203627; Fri, 07 Jun 2024 17:06:43 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 7 Jun 2024 17:06:32 -0700 In-Reply-To: <20240608000639.3295768-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: <20240608000639.3295768-1-seanjc@google.com> X-Mailer: git-send-email 2.45.2.505.gda0bf45e8d-goog Message-ID: <20240608000639.3295768-2-seanjc@google.com> Subject: [PATCH v3 1/8] KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Gao , Kai Huang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock= ); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(), but actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x= 179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e= 0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 synchronize_srcu_expedited+0x21/0x30 kvm_swap_active_memslots+0x110/0x1c0 [kvm] kvm_set_memslot+0x360/0x620 [kvm] __kvm_set_memory_region+0x27b/0x300 [kvm] kvm_vm_ioctl_set_memory_region+0x43/0x60 [kvm] kvm_vm_ioctl+0x295/0x650 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&kvm->slots_lock){+.+.}-{3:3}: __lock_acquire+0x15ef/0x2e30 lock_acquire+0xe0/0x260 __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 set_nx_huge_pages+0x179/0x1e0 [kvm] param_attr_store+0x93/0x100 module_attr_store+0x22/0x40 sysfs_kf_write+0x81/0xb0 kernfs_fop_write_iter+0x133/0x1d0 vfs_write+0x28d/0x380 ksys_write+0x70/0xe0 __x64_sys_write+0x1f/0x30 x64_sys_call+0x281b/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Cc: Chao Gao Fixes: 0bf50497f03b ("KVM: Drop kvm_count_lock and instead protect kvm_usag= e_count with kvm_lock") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Acked-by: Kai Huang Reviewed-by: Kai Huang Tested-by: Farrah Chen --- Documentation/virt/kvm/locking.rst | 19 ++++++++++++------ virt/kvm/kvm_main.c | 31 +++++++++++++++--------------- 2 files changed, 29 insertions(+), 21 deletions(-) diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/lo= cking.rst index 02880d5552d5..5e102fe5b396 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -227,7 +227,13 @@ time it will be set using the Dirty tracking mechanism= described above. :Type: mutex :Arch: any :Protects: - vm_list - - kvm_usage_count + +``kvm_usage_count`` +^^^^^^^^^^^^^^^^^^^ + +:Type: mutex +:Arch: any +:Protects: - kvm_usage_count - hardware virtualization enable/disable :Comment: KVM also disables CPU hotplug via cpus_read_lock() during enable/disable. @@ -290,11 +296,12 @@ time it will be set using the Dirty tracking mechanis= m described above. wakeup. =20 ``vendor_module_lock`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^ :Type: mutex :Arch: x86 :Protects: loading a vendor module (kvm_amd or kvm_intel) -:Comment: Exists because using kvm_lock leads to deadlock. cpu_hotplug_lo= ck is - taken outside of kvm_lock, e.g. in KVM's CPU online/offline callbacks,= and - many operations need to take cpu_hotplug_lock when loading a vendor mo= dule, - e.g. updating static calls. +:Comment: Exists because using kvm_lock leads to deadlock. kvm_lock is ta= ken + in notifiers, e.g. __kvmclock_cpufreq_notifier(), that may be invoked = while + cpu_hotplug_lock is held, e.g. from cpufreq_boost_trigger_state(), and= many + operations need to take cpu_hotplug_lock when loading a vendor module,= e.g. + updating static calls. diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 4965196cad58..d9b0579d3eea 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5499,6 +5499,7 @@ __visible bool kvm_rebooting; EXPORT_SYMBOL_GPL(kvm_rebooting); =20 static DEFINE_PER_CPU(bool, hardware_enabled); +static DEFINE_MUTEX(kvm_usage_lock); static int kvm_usage_count; =20 static int __hardware_enable_nolock(void) @@ -5531,10 +5532,10 @@ static int kvm_online_cpu(unsigned int cpu) * be enabled. Otherwise running VMs would encounter unrecoverable * errors when scheduled to this CPU. */ - mutex_lock(&kvm_lock); + mutex_lock(&kvm_usage_lock); if (kvm_usage_count) ret =3D __hardware_enable_nolock(); - mutex_unlock(&kvm_lock); + mutex_unlock(&kvm_usage_lock); return ret; } =20 @@ -5554,10 +5555,10 @@ static void hardware_disable_nolock(void *junk) =20 static int kvm_offline_cpu(unsigned int cpu) { - mutex_lock(&kvm_lock); + mutex_lock(&kvm_usage_lock); if (kvm_usage_count) hardware_disable_nolock(NULL); - mutex_unlock(&kvm_lock); + mutex_unlock(&kvm_usage_lock); return 0; } =20 @@ -5573,9 +5574,9 @@ static void hardware_disable_all_nolock(void) static void hardware_disable_all(void) { cpus_read_lock(); - mutex_lock(&kvm_lock); + mutex_lock(&kvm_usage_lock); hardware_disable_all_nolock(); - mutex_unlock(&kvm_lock); + mutex_unlock(&kvm_usage_lock); cpus_read_unlock(); } =20 @@ -5606,7 +5607,7 @@ static int hardware_enable_all(void) * enable hardware multiple times. */ cpus_read_lock(); - mutex_lock(&kvm_lock); + mutex_lock(&kvm_usage_lock); =20 r =3D 0; =20 @@ -5620,7 +5621,7 @@ static int hardware_enable_all(void) } } =20 - mutex_unlock(&kvm_lock); + mutex_unlock(&kvm_usage_lock); cpus_read_unlock(); =20 return r; @@ -5648,13 +5649,13 @@ static int kvm_suspend(void) { /* * Secondary CPUs and CPU hotplug are disabled across the suspend/resume - * callbacks, i.e. no need to acquire kvm_lock to ensure the usage count - * is stable. Assert that kvm_lock is not held to ensure the system - * isn't suspended while KVM is enabling hardware. Hardware enabling - * can be preempted, but the task cannot be frozen until it has dropped - * all locks (userspace tasks are frozen via a fake signal). + * callbacks, i.e. no need to acquire kvm_usage_lock to ensure the usage + * count is stable. Assert that kvm_usage_lock is not held to ensure + * the system isn't suspended while KVM is enabling hardware. Hardware + * enabling can be preempted, but the task cannot be frozen until it has + * dropped all locks (userspace tasks are frozen via a fake signal). */ - lockdep_assert_not_held(&kvm_lock); + lockdep_assert_not_held(&kvm_usage_lock); lockdep_assert_irqs_disabled(); =20 if (kvm_usage_count) @@ -5664,7 +5665,7 @@ static int kvm_suspend(void) =20 static void kvm_resume(void) { - lockdep_assert_not_held(&kvm_lock); + lockdep_assert_not_held(&kvm_usage_lock); lockdep_assert_irqs_disabled(); =20 if (kvm_usage_count) --=20 2.45.2.505.gda0bf45e8d-goog From nobody Thu Feb 12 19:05:42 2026 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 84E5128E7 for ; Sat, 8 Jun 2024 00:06:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805208; cv=none; b=u/SEEgQjfLPgPZlknkw8GQhf7zUzS0oowf/WakZ6rnqejQIU4LR06HpDsHwNQEy/PPAYNAMhTRK8UYRSbE7FwdWpt98DQ7XG9aBOY3dA1cUJcSWDqUWASvQQyRevOob+MTEcB9uOKbfB0iK8E3Pvf7a1Ueq57Baxy/cQ14I5S7k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805208; c=relaxed/simple; bh=Z9cQiqCM7hbNpA06nsciQ9usUI929x4+2L/O+6mKe9Y=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ZW66VbMu0z6ZLWz/ROCz0uigzsySZaRWuMmL4wpNgaSMIsGVRAExsHpYOKyVS/l6/X5/5K8vknCqaFR0OZQh3LVrnmPlbF36LtV3XJNWlYwtu/3R9pYaUJ2LsF93t/iqAaNxrpLa3tbg8k9/5jeIWjs8dA4ddt0+dRcbTXp4sX4= 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=MGqZACxm; arc=none smtp.client-ip=209.85.216.73 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="MGqZACxm" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2c2d0e695d7so661046a91.1 for ; Fri, 07 Jun 2024 17:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717805206; x=1718410006; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=Y7jRC7mrAmyRprGwM6jxI+f+KhszVr6gb5pmkxB7ZXA=; b=MGqZACxmOzh0Pjd17d6bvLahP7/oDnheITmyAsszZhDex11lRdsoRAAr6wVIjkkYT/ vuZvEK2luMj47NGCW69HiFdMnlBJNbi+gDse+Uk/5OtUcV4ABqpWaEX6j0vJnHO3lFG6 UVjsEYHsFnQCTdM+qXbbzpT6DFuFs5KRRWagrC5zTPWbHLVP1Wtcu1EAYGxoBuA7JZpz 3a6nRVvWfXmIkvP+7HJtXbqiKL86y/F0Ax+SjOii8YC8Q6W/PzdQQBbEMx0JR42Zja5s lnG0dwa4+qHaEBkJ0sguM+fTsia1OaasdrBtxsVr+V6XZaOqBBZ9HFR//tE+KdtOwyFO xIxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717805206; x=1718410006; h=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; bh=Y7jRC7mrAmyRprGwM6jxI+f+KhszVr6gb5pmkxB7ZXA=; b=uRxhPXg4C7QRaKS5HexBeFiXv/fkfcke/itkwKXLtmxqcm6aHkhA42YU8aV83KtJld pHUzv6ydIOHBgi/iawAgXw462zXYkrQv+Nsaw2IC22+4/AXrrIFVUHNTQxpIiRy0n2wd wGPGzqvffpygVaPxYoFr7eQh6gHzH5AULslP+ur9wVZUYPwSPeId3YvI0usf3O8T9b7B 1he5bUCh3nDsOkO7100+2Wrv16dBUuSnRBIIKEyvoyyyN2JeIKAGccl6FNVSllYrVQj3 kYm997zPoIjQRy8Z+0IzPmVyhM2OIo/xYcfi+Msl/kjE/n8LQFHsgIE1szrbPfU33mHk H0Iw== X-Forwarded-Encrypted: i=1; AJvYcCUgxS1kP+CwcYPa9TW0EFsm93Kn4LR6bweL9Jm1NtdSSyuLMBDcmKd22V6prVD2LZzkNZohK8hO0VAhB+5TJh5oFxGcZHCkFppVrrgW X-Gm-Message-State: AOJu0Yy05HAVxtSZbep32qIurDN/DYZN9MInvnu1LAPlpSszVaZ45KVp 6eUosL4L2Ra+H/eFa8IQwrpBVaMDFkewMSp0ocRxUFePro0nDrNPlBDikJyNfwGCA8hAKxZCDQU tUQ== X-Google-Smtp-Source: AGHT+IFf695AOM2a+ignEkEKz7vbC9tOTvuHErDOawu22pUXoiH1M2cUxhsxJpINQZK9PHGRZkrPmcj7XLA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:ed03:b0:2bd:e2fd:a089 with SMTP id 98e67ed59e1d1-2c2bc79dd1cmr9867a91.0.1717805205652; Fri, 07 Jun 2024 17:06:45 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 7 Jun 2024 17:06:33 -0700 In-Reply-To: <20240608000639.3295768-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: <20240608000639.3295768-1-seanjc@google.com> X-Mailer: git-send-email 2.45.2.505.gda0bf45e8d-goog Message-ID: <20240608000639.3295768-3-seanjc@google.com> Subject: [PATCH v3 2/8] KVM: Register cpuhp and syscore callbacks when enabling hardware From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Gao , Kai Huang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Register KVM's cpuhp and syscore callback when enabling virtualization in hardware instead of registering the callbacks during initialization, and let the CPU up/down framework invoke the inner enable/disable functions. Registering the callbacks during initialization makes things more complex than they need to be, as KVM needs to be very careful about handling races between enabling CPUs being onlined/offlined and hardware being enabled/disabled. Intel TDX support will require KVM to enable virtualization during KVM initialization, i.e. will add another wrinkle to things, at which point sorting out the potential races with kvm_usage_count would become even more complex. Note, using the cpuhp framework has a subtle behavioral change: enabling will be done serially across all CPUs, whereas KVM currently sends an IPI to all CPUs in parallel. While serializing virtualization enabling could create undesirable latency, the issue is limited to creation of KVM's first VM, and even that can be mitigated, e.g. by letting userspace force virtualization to be enabled when KVM is initialized. Cc: Chao Gao Signed-off-by: Sean Christopherson Acked-by: Kai Huang Reviewed-by: Kai Huang Tested-by: Farrah Chen --- virt/kvm/kvm_main.c | 174 ++++++++++++++++---------------------------- 1 file changed, 61 insertions(+), 113 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index d9b0579d3eea..f6b114f42433 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5502,7 +5502,7 @@ static DEFINE_PER_CPU(bool, hardware_enabled); static DEFINE_MUTEX(kvm_usage_lock); static int kvm_usage_count; =20 -static int __hardware_enable_nolock(void) +static int hardware_enable_nolock(void) { if (__this_cpu_read(hardware_enabled)) return 0; @@ -5517,34 +5517,18 @@ static int __hardware_enable_nolock(void) return 0; } =20 -static void hardware_enable_nolock(void *failed) -{ - if (__hardware_enable_nolock()) - atomic_inc(failed); -} - static int kvm_online_cpu(unsigned int cpu) { - int ret =3D 0; - /* * Abort the CPU online process if hardware virtualization cannot * be enabled. Otherwise running VMs would encounter unrecoverable * errors when scheduled to this CPU. */ - mutex_lock(&kvm_usage_lock); - if (kvm_usage_count) - ret =3D __hardware_enable_nolock(); - mutex_unlock(&kvm_usage_lock); - return ret; + return hardware_enable_nolock(); } =20 static void hardware_disable_nolock(void *junk) { - /* - * Note, hardware_disable_all_nolock() tells all online CPUs to disable - * hardware, not just CPUs that successfully enabled hardware! - */ if (!__this_cpu_read(hardware_enabled)) return; =20 @@ -5555,78 +5539,10 @@ static void hardware_disable_nolock(void *junk) =20 static int kvm_offline_cpu(unsigned int cpu) { - mutex_lock(&kvm_usage_lock); - if (kvm_usage_count) - hardware_disable_nolock(NULL); - mutex_unlock(&kvm_usage_lock); + hardware_disable_nolock(NULL); return 0; } =20 -static void hardware_disable_all_nolock(void) -{ - BUG_ON(!kvm_usage_count); - - kvm_usage_count--; - if (!kvm_usage_count) - on_each_cpu(hardware_disable_nolock, NULL, 1); -} - -static void hardware_disable_all(void) -{ - cpus_read_lock(); - mutex_lock(&kvm_usage_lock); - hardware_disable_all_nolock(); - mutex_unlock(&kvm_usage_lock); - cpus_read_unlock(); -} - -static int hardware_enable_all(void) -{ - atomic_t failed =3D ATOMIC_INIT(0); - int r; - - /* - * Do not enable hardware virtualization if the system is going down. - * If userspace initiated a forced reboot, e.g. reboot -f, then it's - * possible for an in-flight KVM_CREATE_VM to trigger hardware enabling - * after kvm_reboot() is called. Note, this relies on system_state - * being set _before_ kvm_reboot(), which is why KVM uses a syscore ops - * hook instead of registering a dedicated reboot notifier (the latter - * runs before system_state is updated). - */ - if (system_state =3D=3D SYSTEM_HALT || system_state =3D=3D SYSTEM_POWER_O= FF || - system_state =3D=3D SYSTEM_RESTART) - return -EBUSY; - - /* - * When onlining a CPU, cpu_online_mask is set before kvm_online_cpu() - * is called, and so on_each_cpu() between them includes the CPU that - * is being onlined. As a result, hardware_enable_nolock() may get - * invoked before kvm_online_cpu(), which also enables hardware if the - * usage count is non-zero. Disable CPU hotplug to avoid attempting to - * enable hardware multiple times. - */ - cpus_read_lock(); - mutex_lock(&kvm_usage_lock); - - r =3D 0; - - kvm_usage_count++; - if (kvm_usage_count =3D=3D 1) { - on_each_cpu(hardware_enable_nolock, &failed, 1); - - if (atomic_read(&failed)) { - hardware_disable_all_nolock(); - r =3D -EBUSY; - } - } - - mutex_unlock(&kvm_usage_lock); - cpus_read_unlock(); - - return r; -} - static void kvm_shutdown(void) { /* @@ -5658,8 +5574,7 @@ static int kvm_suspend(void) lockdep_assert_not_held(&kvm_usage_lock); lockdep_assert_irqs_disabled(); =20 - if (kvm_usage_count) - hardware_disable_nolock(NULL); + hardware_disable_nolock(NULL); return 0; } =20 @@ -5668,8 +5583,7 @@ static void kvm_resume(void) lockdep_assert_not_held(&kvm_usage_lock); lockdep_assert_irqs_disabled(); =20 - if (kvm_usage_count) - WARN_ON_ONCE(__hardware_enable_nolock()); + WARN_ON_ONCE(hardware_enable_nolock()); } =20 static struct syscore_ops kvm_syscore_ops =3D { @@ -5677,6 +5591,60 @@ static struct syscore_ops kvm_syscore_ops =3D { .resume =3D kvm_resume, .shutdown =3D kvm_shutdown, }; + +static int hardware_enable_all(void) +{ + int r; + + guard(mutex)(&kvm_usage_lock); + + if (kvm_usage_count++) + return 0; + + r =3D cpuhp_setup_state(CPUHP_AP_KVM_ONLINE, "kvm/cpu:online", + kvm_online_cpu, kvm_offline_cpu); + if (r) + goto err_cpuhp; + + register_syscore_ops(&kvm_syscore_ops); + + /* + * Undo virtualization enabling and bail if the system is going down. + * If userspace initiated a forced reboot, e.g. reboot -f, then it's + * possible for an in-flight operation to enable virtualization after + * syscore_shutdown() is called, i.e. without kvm_shutdown() being + * invoked. Note, this relies on system_state being set _before_ + * kvm_shutdown(), e.g. to ensure either kvm_shutdown() is invoked + * or this CPU observes the impending shutdown. Which is why KVM uses + * a syscore ops hook instead of registering a dedicated reboot + * notifier (the latter runs before system_state is updated). + */ + if (system_state =3D=3D SYSTEM_HALT || system_state =3D=3D SYSTEM_POWER_O= FF || + system_state =3D=3D SYSTEM_RESTART) { + r =3D -EBUSY; + goto err_rebooting; + } + + return 0; + +err_rebooting: + unregister_syscore_ops(&kvm_syscore_ops); + cpuhp_remove_state(CPUHP_AP_KVM_ONLINE); +err_cpuhp: + --kvm_usage_count; + return r; +} + +static void hardware_disable_all(void) +{ + guard(mutex)(&kvm_usage_lock); + + if (--kvm_usage_count) + return; + + unregister_syscore_ops(&kvm_syscore_ops); + cpuhp_remove_state(CPUHP_AP_KVM_ONLINE); +} #else /* CONFIG_KVM_GENERIC_HARDWARE_ENABLING */ static int hardware_enable_all(void) { @@ -6382,15 +6350,6 @@ int kvm_init(unsigned vcpu_size, unsigned vcpu_align= , struct module *module) int r; int cpu; =20 -#ifdef CONFIG_KVM_GENERIC_HARDWARE_ENABLING - r =3D cpuhp_setup_state_nocalls(CPUHP_AP_KVM_ONLINE, "kvm/cpu:online", - kvm_online_cpu, kvm_offline_cpu); - if (r) - return r; - - register_syscore_ops(&kvm_syscore_ops); -#endif - /* A kmem cache lets us meet the alignment requirements of fx_save. */ if (!vcpu_align) vcpu_align =3D __alignof__(struct kvm_vcpu); @@ -6401,10 +6360,8 @@ int kvm_init(unsigned vcpu_size, unsigned vcpu_align= , struct module *module) offsetofend(struct kvm_vcpu, stats_id) - offsetof(struct kvm_vcpu, arch), NULL); - if (!kvm_vcpu_cache) { - r =3D -ENOMEM; - goto err_vcpu_cache; - } + if (!kvm_vcpu_cache) + return -ENOMEM; =20 for_each_possible_cpu(cpu) { if (!alloc_cpumask_var_node(&per_cpu(cpu_kick_mask, cpu), @@ -6461,11 +6418,6 @@ int kvm_init(unsigned vcpu_size, unsigned vcpu_align= , struct module *module) for_each_possible_cpu(cpu) free_cpumask_var(per_cpu(cpu_kick_mask, cpu)); kmem_cache_destroy(kvm_vcpu_cache); -err_vcpu_cache: -#ifdef CONFIG_KVM_GENERIC_HARDWARE_ENABLING - unregister_syscore_ops(&kvm_syscore_ops); - cpuhp_remove_state_nocalls(CPUHP_AP_KVM_ONLINE); -#endif return r; } EXPORT_SYMBOL_GPL(kvm_init); @@ -6487,10 +6439,6 @@ void kvm_exit(void) kmem_cache_destroy(kvm_vcpu_cache); kvm_vfio_ops_exit(); kvm_async_pf_deinit(); -#ifdef CONFIG_KVM_GENERIC_HARDWARE_ENABLING - unregister_syscore_ops(&kvm_syscore_ops); - cpuhp_remove_state_nocalls(CPUHP_AP_KVM_ONLINE); -#endif kvm_irqfd_exit(); } EXPORT_SYMBOL_GPL(kvm_exit); --=20 2.45.2.505.gda0bf45e8d-goog From nobody Thu Feb 12 19:05:42 2026 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (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 7EB12610C for ; Sat, 8 Jun 2024 00:06:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805210; cv=none; b=FuvvQXYGCFv+DJowIWjf9SUoChZU6zdZ2taYr32Wi/qEX3tjjuEvLM0AEpACvS7XQfUKIQgMHuUoSMz06fzCPg2vcqy+eZ1mAlcRZJWQjIt1/KW68lwO/6Xm8mujk5bzzC+YCa/Tn4mweTAjSRbTkkis6gEj11mRBJuuRNx2bpU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805210; c=relaxed/simple; bh=/RdPxhM/6HHEDqv6agcyx/TVxEplMU6sNYeT51ttpZo=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Ho/tOvI4mq7DhXnl1Kk7NTTPFF70nLj0x4DOwvH0/lSeEKwfvny4pVBh5hZ6es4vAKftER3Gen2wZSyOBRClO2WcSGGHe/K1c+IpnSBmrU5hpH3j05Nn6AOew1CfF3YHQliAKBpMe2ATJbEBh0bmLXI0dk3FNDnG2ZMydJE2REA= 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=XN9w915w; arc=none smtp.client-ip=209.85.215.202 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="XN9w915w" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-6c8f99fef10so2451607a12.3 for ; Fri, 07 Jun 2024 17:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717805208; x=1718410008; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=6oG2p3ebAbUpQGVelwukytqESKts/k/4HZBdB34fsng=; b=XN9w915wTqmJxdAJuxOU5fYBHAZax4NN4UM5MbF4XPV9bM6ZLVN6FIFi6CnRAB3pH5 K43mDknMSeIhi9n4Ip7vTad1YOhRDj0wWXkuAoI+UiRWML/5k9r6LwGSSkHVRsCQ6AiP OcX08mykLh9sZzbizs1yvGvZv84WXLhMQQlpmDev5BjcHmkDS+tknAcjxqiz4ZM+/GHC hAbWxX28+a8YdU3ASeXaqvIzsF/xFcUlZPgJGLQVhEd+oxQcF0T40gqxfGO0rTA09SdD 89LVFiLod3R9M/qadwWXczNfCTxc1QuJCyVB89MG2G2b90EV+BfVVwwUt5h9u9GsfYro HKag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717805208; x=1718410008; h=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; bh=6oG2p3ebAbUpQGVelwukytqESKts/k/4HZBdB34fsng=; b=oMxHueqroEdZB9+kTKvZJ1umMZsE0oJ9dr3GnJsFODoQqQew730XsQcl/cc+SzUMF5 s/Qz/o91NVUEJfEUzK8vBLEeh/D24/IXo7dECVC9U8ghNzzvuPSZQubx3KlB5q5NKc1x lXLpzXnDAhk2fL1X96ZOinq8o2Ef8ALQs8krESlqhfqKQ25oVgpbyqNeWSBZfGRI7ywx yH8tl9gpYOW3qrCxduRyf4mkSGLMctbUqtV45808pSqiyLoVCX7n0qzk5g1zeaaipqTy JRHV93Sl/ljPtHtcTo53J5R+JjhAJPYyUUYx+NHgKXNeRCWuulhdB7HnX1vahbpENDm3 CJQg== X-Forwarded-Encrypted: i=1; AJvYcCW6B8LVKVpYXbXmb5dpqhjF22ErIO11pyqjZtEElJBbezEVPAScjEFeGfX5xy8gFuBmZDmHctktBHCtkPzPm4TLvBrRFlsPy1Irqdhf X-Gm-Message-State: AOJu0Ywv9xL3R65cvreeZqHFxkxTySBEypsOXthaXODlPwiqTRp5fOWQ fMBfnIV1PGzIWN7a8H6lE5OGZaHl2zXGU6YUugEj2Tch9sWz7WeOM48zYCYUF/sl2xRGl+g7LwW Xyg== X-Google-Smtp-Source: AGHT+IFF8X6W+8keGGC1Re8qrc+mhMogVqkIz1hWPolngotghqPZz/mK4Jjg1VkUoBzN/qU5TGWbg7vW83I= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a65:5c85:0:b0:65b:7bff:881b with SMTP id 41be03b00d2f7-6e15ebbfb56mr9302a12.8.1717805207578; Fri, 07 Jun 2024 17:06:47 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 7 Jun 2024 17:06:34 -0700 In-Reply-To: <20240608000639.3295768-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: <20240608000639.3295768-1-seanjc@google.com> X-Mailer: git-send-email 2.45.2.505.gda0bf45e8d-goog Message-ID: <20240608000639.3295768-4-seanjc@google.com> Subject: [PATCH v3 3/8] KVM: Rename functions related to enabling virtualization hardware From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Gao , Kai Huang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Rename the various functions that enable virtualization to prepare for upcoming changes, and to clean up artifacts of KVM's previous behavior, which required manually juggling locks around kvm_usage_count. Drop the "nolock" qualifier from per-CPU functions now that there are no "nolock" implementations of the "all" variants, i.e. now that calling a non-nolock function from a nolock function isn't confusing (unlike this sentence). Drop "all" from the outer helpers as they no longer manually iterate over all CPUs, and because it might not be obvious what "all" refers to. Instead, use double-underscores to communicate that the per-CPU functions are helpers to the outer APIs. Opportunistically prepend "kvm" to all functions to help make it clear that they are KVM helpers, but mostly there's no reason not to. Lastly, use "virtualization" instead of "hardware", because while the functions do enable virtualization in hardware, there are a _lot_ of things that KVM enables in hardware. Reviewed-by: Chao Gao Reviewed-by: Kai Huang Signed-off-by: Sean Christopherson Acked-by: Kai Huang Tested-by: Farrah Chen --- virt/kvm/kvm_main.c | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index f6b114f42433..98e52d12f137 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -138,8 +138,8 @@ static int kvm_no_compat_open(struct inode *inode, stru= ct file *file) #define KVM_COMPAT(c) .compat_ioctl =3D kvm_no_compat_ioctl, \ .open =3D kvm_no_compat_open #endif -static int hardware_enable_all(void); -static void hardware_disable_all(void); +static int kvm_enable_virtualization(void); +static void kvm_disable_virtualization(void); =20 static void kvm_io_bus_destroy(struct kvm_io_bus *bus); =20 @@ -1215,7 +1215,7 @@ static struct kvm *kvm_create_vm(unsigned long type, = const char *fdname) if (r) goto out_err_no_arch_destroy_vm; =20 - r =3D hardware_enable_all(); + r =3D kvm_enable_virtualization(); if (r) goto out_err_no_disable; =20 @@ -1258,7 +1258,7 @@ static struct kvm *kvm_create_vm(unsigned long type, = const char *fdname) mmu_notifier_unregister(&kvm->mmu_notifier, current->mm); #endif out_err_no_mmu_notifier: - hardware_disable_all(); + kvm_disable_virtualization(); out_err_no_disable: kvm_arch_destroy_vm(kvm); out_err_no_arch_destroy_vm: @@ -1353,7 +1353,7 @@ static void kvm_destroy_vm(struct kvm *kvm) #endif kvm_arch_free_vm(kvm); preempt_notifier_dec(); - hardware_disable_all(); + kvm_disable_virtualization(); mmdrop(mm); } =20 @@ -5502,7 +5502,7 @@ static DEFINE_PER_CPU(bool, hardware_enabled); static DEFINE_MUTEX(kvm_usage_lock); static int kvm_usage_count; =20 -static int hardware_enable_nolock(void) +static int __kvm_enable_virtualization(void) { if (__this_cpu_read(hardware_enabled)) return 0; @@ -5524,10 +5524,10 @@ static int kvm_online_cpu(unsigned int cpu) * be enabled. Otherwise running VMs would encounter unrecoverable * errors when scheduled to this CPU. */ - return hardware_enable_nolock(); + return __kvm_enable_virtualization(); } =20 -static void hardware_disable_nolock(void *junk) +static void __kvm_disable_virtualization(void *ign) { if (!__this_cpu_read(hardware_enabled)) return; @@ -5539,7 +5539,7 @@ static void hardware_disable_nolock(void *junk) =20 static int kvm_offline_cpu(unsigned int cpu) { - hardware_disable_nolock(NULL); + __kvm_disable_virtualization(NULL); return 0; } =20 @@ -5558,7 +5558,7 @@ static void kvm_shutdown(void) */ pr_info("kvm: exiting hardware virtualization\n"); kvm_rebooting =3D true; - on_each_cpu(hardware_disable_nolock, NULL, 1); + on_each_cpu(__kvm_disable_virtualization, NULL, 1); } =20 static int kvm_suspend(void) @@ -5574,7 +5574,7 @@ static int kvm_suspend(void) lockdep_assert_not_held(&kvm_usage_lock); lockdep_assert_irqs_disabled(); =20 - hardware_disable_nolock(NULL); + __kvm_disable_virtualization(NULL); return 0; } =20 @@ -5583,7 +5583,7 @@ static void kvm_resume(void) lockdep_assert_not_held(&kvm_usage_lock); lockdep_assert_irqs_disabled(); =20 - WARN_ON_ONCE(hardware_enable_nolock()); + WARN_ON_ONCE(__kvm_enable_virtualization()); } =20 static struct syscore_ops kvm_syscore_ops =3D { @@ -5592,7 +5592,7 @@ static struct syscore_ops kvm_syscore_ops =3D { .shutdown =3D kvm_shutdown, }; =20 -static int hardware_enable_all(void) +static int kvm_enable_virtualization(void) { int r; =20 @@ -5635,7 +5635,7 @@ static int hardware_enable_all(void) return r; } =20 -static void hardware_disable_all(void) +static void kvm_disable_virtualization(void) { guard(mutex)(&kvm_usage_lock); =20 @@ -5646,12 +5646,12 @@ static void hardware_disable_all(void) cpuhp_remove_state(CPUHP_AP_KVM_ONLINE); } #else /* CONFIG_KVM_GENERIC_HARDWARE_ENABLING */ -static int hardware_enable_all(void) +static int kvm_enable_virtualization(void) { return 0; } =20 -static void hardware_disable_all(void) +static void kvm_disable_virtualization(void) { =20 } --=20 2.45.2.505.gda0bf45e8d-goog From nobody Thu Feb 12 19:05:42 2026 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.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 8A29BD520 for ; Sat, 8 Jun 2024 00:06:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805212; cv=none; b=kpLoBB6mW5REfYiC+QMsyn0MMlJWhhqGEu7tGJ+xzwwRDTUyC9ozsRjZ7X4vKdWOfmXTlObi4X6JBbOlCgwppz2lXZSh5WNfoHNuClDCYNHgbymLUJe3+9MfPAe78GT4p3i3oySUzsPPe+JsWKw1DWa4Gyy0sed9Afq1gylVVR8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805212; c=relaxed/simple; bh=kosHQz2mO5WsDhLLqPXFZqPb2PZkIqYIvZGswimzFcE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=YZt51uU96QFt6p49wz+w6IQ8EwIgVfhT1lPcZiWcsD6BHLhc/t3TVtsJWvlRG35gbLmnpTMv1EQFZnqMNtCIpGiDaYhbkTz947ybwEegV7M6Z6clWfya4J4yXkVpXTPt6X7mK/GTrhzTZZoYOrIXJilkQNnsKKqzfsSkh3pSxgo= 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=YTC645Sx; arc=none smtp.client-ip=209.85.128.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="YTC645Sx" Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-627dd6a56caso41965277b3.3 for ; Fri, 07 Jun 2024 17:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717805209; x=1718410009; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=U44HT/MSZO+MfGZ9R6nvDDZFtdhwkwnAqQLWwNh4/1A=; b=YTC645Sx/o+2Hf/holcYvVQV2vL1CfjQRv7IO1YIiSkwFwZg9qPFWwTSHRGL2D342+ UmhCDQFrUZhMjqzujwawLsrvhuyiIBN0qDSqFIAnk1Hu0luUqT6Tdf5s58oiuJJZOjAi QSFkaBdGrrEfeDRx/ATFTEUt8kqsDReilNurIjFdi34LoTe77CAYzNe8HCkjziudHehH DzUrXL+kPCrmV/J1qr/eWOua+pLdkN3emVvLRMnMK/2ecEOIENHRVQpH0piCzRxXgzqu qIgDkkzb+26gqAfdsFlc4Qb08RMEa4He+NY2kfClr4QCaJJRz68imWj532NsYgEIqco0 NqGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717805209; x=1718410009; h=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; bh=U44HT/MSZO+MfGZ9R6nvDDZFtdhwkwnAqQLWwNh4/1A=; b=DgaYk1KI3Mb9KCoEYww4W+Wegk4ZwE/xYxpuR3MeX1L074YoNwJOpLXRJk2nfVssA2 unTNP87Ukup8quuNtbrh8Ng7/HAoWOfrzqvF4pVnLSE0zo3uurIKQ89ubVr1tEH3/L3U jgn0knrU2lj3qkR28zoEvjbVLCBP5bsnBf/gtJDeRf5DzNC+WoxSpFRGOAQBaEdZv1uQ RZV3AUH7Yy8+Q75+mWXa9wUVH2pCe/htgCyYUE8YoEfUz2HJnZKMXT32A0oxx41C3lGE Avn4w5D0o1lLn2FVTeMhnTuvsFf/HJ8U0NRknCAERa1SkK7Utrq0zLqOK0IfPjBVQAbm Efuw== X-Forwarded-Encrypted: i=1; AJvYcCW17nEyBuihy3+Q6vBal2tjeJivxzr7eSVuHxMm2POoKVVDlMnpG5v7m4GwEuXU1mlS6CJEZlQzpUsreMt5n2cwpJpSzHINB6+97NpV X-Gm-Message-State: AOJu0YzlRx8fV/AqV6bG0WYbW7k71IvL6Zks3HPNKdheL36uY7t3e3iM qV92cvnUoXBkj7W7zHPn+Hag9o3pQydfMKhxPJjNZ0dvaQxiJl0dl38+fwFHN4Ur8QWUwpaDjBt /+w== X-Google-Smtp-Source: AGHT+IHRwQ4x9TCmQSW6AWp9+/8y2WG7Y4nCfpX6fD0I2kzjUWVv+BUZsTJw8+ZiUMqV0PE2GMOJIENNeyk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:18cf:b0:dfa:48f9:1855 with SMTP id 3f1490d57ef6-dfaf65228b6mr492235276.3.1717805209598; Fri, 07 Jun 2024 17:06:49 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 7 Jun 2024 17:06:35 -0700 In-Reply-To: <20240608000639.3295768-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: <20240608000639.3295768-1-seanjc@google.com> X-Mailer: git-send-email 2.45.2.505.gda0bf45e8d-goog Message-ID: <20240608000639.3295768-5-seanjc@google.com> Subject: [PATCH v3 4/8] KVM: Add a module param to allow enabling virtualization when KVM is loaded From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Gao , Kai Huang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add an off-by-default module param, enable_virt_at_load, to let userspace force virtualization to be enabled in hardware when KVM is initialized, i.e. just before /dev/kvm is exposed to userspace. Enabling virtualization during KVM initialization allows userspace to avoid the additional latency when creating/destroying the first/last VM. Now that KVM uses the cpuhp framework to do per-CPU enabling, the latency could be non-trivial as the cpuhup bringup/teardown is serialized across CPUs, e.g. the latency could be problematic for use case that need to spin up VMs quickly. Enabling virtualizaton during initialization will also allow KVM to setup the Intel TDX Module, which requires VMX to be fully enabled, without needing additional APIs to temporarily enable virtualization. Signed-off-by: Sean Christopherson Acked-by: Kai Huang Tested-by: Farrah Chen --- virt/kvm/kvm_main.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 98e52d12f137..7bdd744e4821 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5495,6 +5495,9 @@ static struct miscdevice kvm_dev =3D { }; =20 #ifdef CONFIG_KVM_GENERIC_HARDWARE_ENABLING +static bool enable_virt_at_load; +module_param(enable_virt_at_load, bool, 0444); + __visible bool kvm_rebooting; EXPORT_SYMBOL_GPL(kvm_rebooting); =20 @@ -5645,15 +5648,41 @@ static void kvm_disable_virtualization(void) unregister_syscore_ops(&kvm_syscore_ops); cpuhp_remove_state(CPUHP_AP_KVM_ONLINE); } + +static int kvm_init_virtualization(void) +{ + if (enable_virt_at_load) + return kvm_enable_virtualization(); + + return 0; +} + +static void kvm_uninit_virtualization(void) +{ + if (enable_virt_at_load) + kvm_disable_virtualization(); + + WARN_ON(kvm_usage_count); +} #else /* CONFIG_KVM_GENERIC_HARDWARE_ENABLING */ static int kvm_enable_virtualization(void) { return 0; } =20 +static int kvm_init_virtualization(void) +{ + return 0; +} + static void kvm_disable_virtualization(void) { =20 +} + +static void kvm_uninit_virtualization(void) +{ + } #endif /* CONFIG_KVM_GENERIC_HARDWARE_ENABLING */ =20 @@ -6395,6 +6424,10 @@ int kvm_init(unsigned vcpu_size, unsigned vcpu_align= , struct module *module) =20 kvm_gmem_init(module); =20 + r =3D kvm_init_virtualization(); + if (r) + goto err_virt; + /* * Registration _must_ be the very last thing done, as this exposes * /dev/kvm to userspace, i.e. all infrastructure must be setup! @@ -6408,6 +6441,8 @@ int kvm_init(unsigned vcpu_size, unsigned vcpu_align,= struct module *module) return 0; =20 err_register: + kvm_uninit_virtualization(); +err_virt: kvm_vfio_ops_exit(); err_vfio: kvm_async_pf_deinit(); @@ -6433,6 +6468,8 @@ void kvm_exit(void) */ misc_deregister(&kvm_dev); =20 + kvm_uninit_virtualization(); + debugfs_remove_recursive(kvm_debugfs_dir); for_each_possible_cpu(cpu) free_cpumask_var(per_cpu(cpu_kick_mask, cpu)); --=20 2.45.2.505.gda0bf45e8d-goog From nobody Thu Feb 12 19:05:42 2026 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (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 298F517C8 for ; Sat, 8 Jun 2024 00:06:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805213; cv=none; b=JAe+SQDpN6IPX/nyYUXPClh4IoEpz9/uq9FZ38dpz87+cuLYFmSU9CIoYzO3TqBxslLsc+cKk6boZjPs5yUK3PQM8KdQUbAtOONb7EFZwFntAxFMrzH1460AiEcz4GaJCTQtA3FYeAogkz2hfGQnnL9DHUj4ef60RGRdDwvQWTc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805213; c=relaxed/simple; bh=CQMK/h9eb5oR6ViVQX4U3uFGNRM5CkCgrRNqS7xc64k=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=N9mCKw+92JWwS95g8z9pO5rOxrTZm7mVXbZjaB31rkrsvH2PSt4qHc9Vx4VK37/ISr8RebDvzu+IIASCUyxPhvZgEbCz7anxtrVDBFgfQwXzByNGbmGk1ZEtxAvstwD8dnr5Bt96js4Q7quuxQ6yEPB2iyKgxw+FqYA14Uvjz6I= 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=TKnyr3DM; arc=none smtp.client-ip=209.85.215.202 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="TKnyr3DM" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-6e4381588c8so1169334a12.2 for ; Fri, 07 Jun 2024 17:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717805211; x=1718410011; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=hcN62n3eAvJ+wQBQZ24js4P4o2/e149QwTHEtQT2vY4=; b=TKnyr3DMIrUaxY21uPkzmiRNOlkXMfQzAPvk5ka/SWee2REQNZVmqzEaAaFdgROC2e 8bGZKv4B7ASktF2st8uxd5O+ydEKaOpDh1+cz0fLIrFb8KcMQWcKPXBSVxgrCfiT/H3x gz5eAdKZ2JC4zXlNAQgA4/yeoOZASvgVH38DI4sXR6cDEQjq+hoXBtpG9IKbdN3eJNRF cZkigvl9OpzVSS9WGpks1CpmLirVEMS46+ollyYr9E2X9HdJfjB26U3ruw934vMhHeuQ 7dqYJJ98spkuTBoElXfKnCk8aeR9AMuolGHo63TA/HOaYZ/GEBxV/WkPVoyQ3RW1zg/k sSvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717805211; x=1718410011; h=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; bh=hcN62n3eAvJ+wQBQZ24js4P4o2/e149QwTHEtQT2vY4=; b=IqqB2PZlKn/1wTNa5i93Mgm6xOj2L4FD5EY+lIbxm+Ltevrd0FqczqJGbOMocCHnWR GRGw87dlzzEhYronaOBCcvdiiCctGF3xV+Mg/IdZMgs6uwaQQgFdmeyKL5hlKHnU9wzQ HbxgHtE57ZfVbmzvdusu8wfhSRCbFeSHa4lxI6V94UBi4JA3lOo2rJdSOXRYS2FQfuJo PUOJ9xa68o9YO1LIbHU8gnHCjslO68MImwWY7bx/e03H7xvv/vE+gT6ym1fLdpbwdnos 2uO59kFIcUoQSnMV18DTHQkdgd66PEFiO0LEPx4eEtPLix3TSvaLAseZENFxsBstPNJE vIVg== X-Forwarded-Encrypted: i=1; AJvYcCW8QZD0HLMv7Uc95SQKbJYJIUzNnN59JJjo5GaptYOOLShJw1d649Gvjw8vHRQzzXXJ2ZRwewKSMmMaHcnaMKIMwRzoun2apcXmsEOb X-Gm-Message-State: AOJu0Yx3DcIC8FFjGc7ShJso5SWVSdbMwAM9HkOwVk6MmW7k2pq0f97K yX344GxrflcO9DA2Y/burK3ismCel5D+1P3aLdOLF4LFXLgQPJ8MrTJkq6XxPAyXwLfuFq0Uzfr ZBA== X-Google-Smtp-Source: AGHT+IGqgoQIgsdgjc/QsCSr0LlLIFd2eln/NUclIt/hIDKFvlhwEYksb1GJZEUAX2hQBnqbPh5Y3juuvUA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a63:4e03:0:b0:659:23db:a4b2 with SMTP id 41be03b00d2f7-6e15eaaf307mr8542a12.8.1717805211114; Fri, 07 Jun 2024 17:06:51 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 7 Jun 2024 17:06:36 -0700 In-Reply-To: <20240608000639.3295768-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: <20240608000639.3295768-1-seanjc@google.com> X-Mailer: git-send-email 2.45.2.505.gda0bf45e8d-goog Message-ID: <20240608000639.3295768-6-seanjc@google.com> Subject: [PATCH v3 5/8] KVM: Add arch hooks for enabling/disabling virtualization From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Gao , Kai Huang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add arch hooks that are invoked when KVM enables/disable virtualization. x86 will use the hooks to register an "emergency disable" callback, which is essentially an x86-specific shutdown notifier that is used when the kernel is doing an emergency reboot/shutdown/kexec. Add comments for the declarations to help arch code understand exactly when the callbacks are invoked. Alternatively, the APIs themselves could communicate most of the same info, but kvm_arch_pre_enable_virtualization() and kvm_arch_post_disable_virtualization() are a bit cumbersome, and make it a bit less obvious that they are intended to be implemented as a pair. Reviewed-by: Chao Gao Reviewed-by: Kai Huang Signed-off-by: Sean Christopherson Acked-by: Kai Huang Tested-by: Farrah Chen --- include/linux/kvm_host.h | 14 ++++++++++++++ virt/kvm/kvm_main.c | 14 ++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 96ad3e8b9ddb..12ef3beb4e47 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1514,6 +1514,20 @@ static inline void kvm_create_vcpu_debugfs(struct kv= m_vcpu *vcpu) {} #endif =20 #ifdef CONFIG_KVM_GENERIC_HARDWARE_ENABLING +/* + * kvm_arch_{enable,disable}_virtualization() are called on one CPU, under + * kvm_usage_lock, immediately after/before 0=3D>1 and 1=3D>0 transitions = of + * kvm_usage_count, i.e. at the beginning of the generic hardware enabling + * sequence, and at the end of the generic hardware disabling sequence. + */ +void kvm_arch_enable_virtualization(void); +void kvm_arch_disable_virtualization(void); +/* + * kvm_arch_hardware_{enable,disable}() are called on "every" CPU to do the + * actual twiddling of hardware bits. The hooks are called all online CPUs + * when KVM enables/disabled virtualization. Enabling/disabling is also d= one + * when a CPU is onlined/offlined (or Resumed/Suspended). + */ int kvm_arch_hardware_enable(void); void kvm_arch_hardware_disable(void); #endif diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 7bdd744e4821..e20189a89a64 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5505,6 +5505,16 @@ static DEFINE_PER_CPU(bool, hardware_enabled); static DEFINE_MUTEX(kvm_usage_lock); static int kvm_usage_count; =20 +__weak void kvm_arch_enable_virtualization(void) +{ + +} + +__weak void kvm_arch_disable_virtualization(void) +{ + +} + static int __kvm_enable_virtualization(void) { if (__this_cpu_read(hardware_enabled)) @@ -5604,6 +5614,8 @@ static int kvm_enable_virtualization(void) if (kvm_usage_count++) return 0; =20 + kvm_arch_enable_virtualization(); + r =3D cpuhp_setup_state(CPUHP_AP_KVM_ONLINE, "kvm/cpu:online", kvm_online_cpu, kvm_offline_cpu); if (r) @@ -5634,6 +5646,7 @@ static int kvm_enable_virtualization(void) unregister_syscore_ops(&kvm_syscore_ops); cpuhp_remove_state(CPUHP_AP_KVM_ONLINE); err_cpuhp: + kvm_arch_disable_virtualization(); --kvm_usage_count; return r; } @@ -5647,6 +5660,7 @@ static void kvm_disable_virtualization(void) =20 unregister_syscore_ops(&kvm_syscore_ops); cpuhp_remove_state(CPUHP_AP_KVM_ONLINE); + kvm_arch_disable_virtualization(); } =20 static int kvm_init_virtualization(void) --=20 2.45.2.505.gda0bf45e8d-goog From nobody Thu Feb 12 19:05:42 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 397241B970 for ; Sat, 8 Jun 2024 00:06:54 +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=1717805215; cv=none; b=HAL2ndBs0ujFp/q77snwJf9UqGuhMNKZoapepzaKgXOdenp5Yiu7uIajfAGa6zERUV6n85J4WUr6OEuUNjQxP/q2uQHdKiT0HU3u09r1syvDeXyepnFvwmm16hr8mB7CTK1wIXN3cWK1VdGDL3USxjUatxK7Mn+J1Ws6LWxJNtM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805215; c=relaxed/simple; bh=+Rgd0uG8zFVDeMbiPveKaoIB6ed40a/lydcxeYv2SLU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=rqPBN40czZOYjk7+3xyHqch2zchrLWEHELsQUVyHl5c4c50Xwzvbu3mRfD6Btr0TCD97mjgP11tuz5nEeHGmngZBntLCHNpBh7VYWgf3/ZuFyZnNn3712E5HVj8mKzbZGYe02lMsmRTE/S2g6tY+9ySj+2N6DxvKr4750ZNUIhI= 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=GE40QlRU; 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="GE40QlRU" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-6c380e03048so2468424a12.3 for ; Fri, 07 Jun 2024 17:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717805213; x=1718410013; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=9BJaexKSfJJd6oXZEzTDtIkjFffas2FF3vn5yJVMfK8=; b=GE40QlRUVmPsTczYGSoz45viAD2CaY7vIiJgOmq1+8pUqqbKP4r4GFb0eYZd3oYtUp PZV/H15eLMiLjWEfvtSDXhIXlqLPJSXIu2pOtfuPWWxMpM+fydK2bU0IFlhT2NuCmlGz UGzAHGgOKAovBZstw7mf07nks4GQUjDXx/Cw2EFEjXS98oeBXLqT6lmMt4RssHKjrX8k uMQE/Y610Z8vKh2P7IA/q8JIf4QIOk33JL/avVKK7qWDDfAwsb5xUU3Le3G529ZyWLAo +9323joRiIW+w7bfhIPm2eR+VSiHixiK+WxoZ6+ao50jrimj1UJbQrMYzouvHMPqchiK 8k1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717805213; x=1718410013; h=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; bh=9BJaexKSfJJd6oXZEzTDtIkjFffas2FF3vn5yJVMfK8=; b=h7xRuFcnXn6mA8BQ9hwtBW0VAJOlGSgHAONjFYclw8uwhF0qsWVPCVoHehFxDclhVV DOm9AmFrezujz4s0nqpeJ6wa8BRn2UBwOFtX0y0OmA79HDwdWswqsEY0uGkJoua666fS CpwbM+l91vm/M1PXvHKejMxOGJEt8yzeS95MKOQzxj6HfBCDE5gzBvvjGnlmNF6eu9Et jWJttbSWaiei628abEydEW5Fnq7U1UU56cS3P77WhP7abHtuS01RUV9fqs3Zcrfhgj8v UdN+hahd+lUkjVa97/mURtbukjd6JMFFO4pf+WDrzeEPV+DMg/xSPNBVQGtHDq2hA8fo pNNQ== X-Forwarded-Encrypted: i=1; AJvYcCW4yj8368uxRDc4JQyu3MTVxrJiiSsSMi5aQOk8i9v76lL+xXG0rnNeLSbzlkUM3OSFcj0A2nqx+E/SPVAWBzJ8O8b/X6OBdS2u/60D X-Gm-Message-State: AOJu0YyXl7ayhNj4N3OKwPc15KzHyxvByDV9qwgdBLuRv4SREHo9xv8J 4cVv7O/xnYHuFSOMp792ycNsIpPIPxJH3qkicRAKdxPiYKnQ0vtSSs9pz2OpoGkd7gf3HSP0bAf cyA== X-Google-Smtp-Source: AGHT+IGSWWVQPTwJRta7zJEdra8ZC8/nCqaYH3EjnTjLAbAgOrfQRgAJ3ikjR3Fon2AfI2+l6m4fHLN4sa8= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:6309:b0:2c0:122d:c534 with SMTP id 98e67ed59e1d1-2c2bcc5f046mr9783a91.7.1717805213214; Fri, 07 Jun 2024 17:06:53 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 7 Jun 2024 17:06:37 -0700 In-Reply-To: <20240608000639.3295768-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: <20240608000639.3295768-1-seanjc@google.com> X-Mailer: git-send-email 2.45.2.505.gda0bf45e8d-goog Message-ID: <20240608000639.3295768-7-seanjc@google.com> Subject: [PATCH v3 6/8] x86/reboot: Unconditionally define cpu_emergency_virt_cb typedef From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Gao , Kai Huang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Define cpu_emergency_virt_cb even if the kernel is being built without KVM support so that KVM can reference the typedef in asm/kvm_host.h without needing yet more #ifdefs. No functional change intended. Acked-by: Kai Huang Reviewed-by: Chao Gao Signed-off-by: Sean Christopherson Tested-by: Farrah Chen --- arch/x86/include/asm/reboot.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/reboot.h b/arch/x86/include/asm/reboot.h index 6536873f8fc0..d0ef2a678d66 100644 --- a/arch/x86/include/asm/reboot.h +++ b/arch/x86/include/asm/reboot.h @@ -25,8 +25,8 @@ void __noreturn machine_real_restart(unsigned int type); #define MRR_BIOS 0 #define MRR_APM 1 =20 -#if IS_ENABLED(CONFIG_KVM_INTEL) || IS_ENABLED(CONFIG_KVM_AMD) typedef void (cpu_emergency_virt_cb)(void); +#if IS_ENABLED(CONFIG_KVM_INTEL) || IS_ENABLED(CONFIG_KVM_AMD) void cpu_emergency_register_virt_callback(cpu_emergency_virt_cb *callback); void cpu_emergency_unregister_virt_callback(cpu_emergency_virt_cb *callbac= k); void cpu_emergency_disable_virtualization(void); --=20 2.45.2.505.gda0bf45e8d-goog From nobody Thu Feb 12 19:05:42 2026 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 EBBA01CD00 for ; Sat, 8 Jun 2024 00:06:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805217; cv=none; b=nVTGCJKYbZ9MIRNKEOD09jEX+Vpuj7d2ZbWR9iNJzoE+s2B5r7RLV5PQLsxV/8QZJ4y0Xrfj5Lo2EmT5ZPMleCQ9TFbA+7oEAdrogd7H+Ko7bd9KK0lucv3CEfKJq/bFE4DguVlrTJwos97YEAnwxAQc1LpRRQsmGKGodVR7ubE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805217; c=relaxed/simple; bh=6kqkQOeGxQkn53M2KEHk2/M5zGfJ/Ga7YB5xxnYelGI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=fGTKBDDLYun9TPm8Hc0Svl94Fi48rFeNLfXUF7A9VHzJn6Mt+mAgl9iOOFd5pded+U3zNWkCpv3WnHhHFj0lXr0Ftz5bKo0gISCdCSpNU1lnD0fieHfGu4Roq1gXUBg7TngH7dKFF8gsGfSHfSqogLn/dmF6piJV9FSek/deVYM= 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=wWddpbZ4; arc=none smtp.client-ip=209.85.216.73 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="wWddpbZ4" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2c283f190c1so1584459a91.1 for ; Fri, 07 Jun 2024 17:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717805215; x=1718410015; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=8TLSuBEX+P1/sjGRLpoZ3jVRlThdpta5sXvxaIB45Jk=; b=wWddpbZ4NNK+xZm6K4oME+hEJvZJ+WfSyIovRMr2M51RD9gtmbadFOonWIjsRgcrO4 NYkF4+WolMVXh9r++3y76uX9bb9+s3ddeCO/ysOAo+LW7qrNxshyC7dqPBpH7T68DkGn ig7nJGpzMhK2Tew8SVrvwOR76DipTvaR4dPPa8M43WvI6A6lpJul/ERXZvcJAYTBYf8O Kr3lExfseSj8FU/jnEDBav1kgL8n42lbPpqPjLdhG2huQ9wCPXF7NHG6p53cVTk3dd1O qvMRZfLw6r1kCPxjElGOEdxkZ9xjgNgi1VmVyj6DhorCoxszTN9x9zuMdlak0uh3lCS8 c+CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717805215; x=1718410015; h=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; bh=8TLSuBEX+P1/sjGRLpoZ3jVRlThdpta5sXvxaIB45Jk=; b=cclcULdZv8uH2TSXG2Okgn1i2SgZCgkhXvf5QRJrkfsoE9/7I44Lvx6CAtjLDwzG5c BSkCbm5g9TvGx0qbYMoHA8uv6trvqjl90QSXYWgQvNPcYosb8NTOjIIVnthkW5FePehi I5s4xzaCOZzJsrnT4V8tGogjKXQjOCjEQqqnLowzpWiCDGvH0v2E6Vsc5a8TlqKOBii9 zbtyteLIueh09yEiS59wHgodLUQMMeT/Fo+ute+vRVhQrd8vRnIANA99rhmFle8/VgZM J0RdBfhuRcUxyqA5M+GDMXt7LW0f2yvoryc6K9DWiqfuHIgNShpW70kRHn7IJpgIsooN PTtg== X-Forwarded-Encrypted: i=1; AJvYcCUn5Up7RrC/9j182QPtXG72Xgu4T0gPM5zGVmJ6Y62pkc6LCJksvtbLYi/iuwPhXkEm6R4tvAPgZpqY5qsG9rJLWKRsCwvBOtRbHUE0 X-Gm-Message-State: AOJu0YyJyjeAuNmmZpbk3N/07mOjnt1us6Lv0SVpXaixrDR2UgewHnps qwM9hm7ykCSw17Jilkxb0xDEq84jzPaJKbgWyBeB0b0xpeYsLEHbAu0tbQThRQvhqvs3/xtI2Sj C7w== X-Google-Smtp-Source: AGHT+IH6oAmMG/Wy9I2jAo5gtN27DcalJ0mI7IJVMh6HVM6DDOqHPpelfrT7QwFjts8KL4lgLd9pZv42vrw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:5d16:b0:2c2:d6e5:535f with SMTP id 98e67ed59e1d1-2c2d6e55433mr2867a91.8.1717805215021; Fri, 07 Jun 2024 17:06:55 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 7 Jun 2024 17:06:38 -0700 In-Reply-To: <20240608000639.3295768-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: <20240608000639.3295768-1-seanjc@google.com> X-Mailer: git-send-email 2.45.2.505.gda0bf45e8d-goog Message-ID: <20240608000639.3295768-8-seanjc@google.com> Subject: [PATCH v3 7/8] KVM: x86: Register "emergency disable" callbacks when virt is enabled From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Gao , Kai Huang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Register the "disable virtualization in an emergency" callback just before KVM enables virtualization in hardware, as there is no functional need to keep the callbacks registered while KVM happens to be loaded, but is inactive, i.e. if KVM hasn't enabled virtualization. Note, unregistering the callback every time the last VM is destroyed could have measurable latency due to the synchronize_rcu() needed to ensure all references to the callback are dropped before KVM is unloaded. But the latency should be a small fraction of the total latency of disabling virtualization across all CPUs, and userspace can set enable_virt_at_load to completely eliminate the runtime overhead. Add a pointer in kvm_x86_ops to allow vendor code to provide its callback. There is no reason to force vendor code to do the registration, and either way KVM would need a new kvm_x86_ops hook. Suggested-by: Kai Huang Reviewed-by: Chao Gao Reviewed-by: Kai Huang Signed-off-by: Sean Christopherson Acked-by: Kai Huang Tested-by: Farrah Chen --- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/svm/svm.c | 5 +---- arch/x86/kvm/vmx/main.c | 2 ++ arch/x86/kvm/vmx/vmx.c | 6 +----- arch/x86/kvm/vmx/x86_ops.h | 1 + arch/x86/kvm/x86.c | 10 ++++++++++ 6 files changed, 18 insertions(+), 9 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 5c0415899a07..a4444b43f575 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -36,6 +36,7 @@ #include #include #include +#include =20 #define __KVM_HAVE_ARCH_VCPU_DEBUGFS =20 @@ -1626,6 +1627,8 @@ struct kvm_x86_ops { =20 int (*hardware_enable)(void); void (*hardware_disable)(void); + cpu_emergency_virt_cb *emergency_disable; + void (*hardware_unsetup)(void); bool (*has_emulated_msr)(struct kvm *kvm, u32 index); void (*vcpu_after_set_cpuid)(struct kvm_vcpu *vcpu); diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index d33193d522e3..aa0aeb185d17 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4981,6 +4981,7 @@ static void *svm_alloc_apic_backing_page(struct kvm_v= cpu *vcpu) static struct kvm_x86_ops svm_x86_ops __initdata =3D { .name =3D KBUILD_MODNAME, =20 + .emergency_disable =3D svm_emergency_disable, .check_processor_compatibility =3D svm_check_processor_compat, =20 .hardware_unsetup =3D svm_hardware_unsetup, @@ -5416,8 +5417,6 @@ static struct kvm_x86_init_ops svm_init_ops __initdat= a =3D { static void __svm_exit(void) { kvm_x86_vendor_exit(); - - cpu_emergency_unregister_virt_callback(svm_emergency_disable); } =20 static int __init svm_init(void) @@ -5433,8 +5432,6 @@ static int __init svm_init(void) if (r) return r; =20 - cpu_emergency_register_virt_callback(svm_emergency_disable); - /* * Common KVM initialization _must_ come last, after this, /dev/kvm is * exposed to userspace! diff --git a/arch/x86/kvm/vmx/main.c b/arch/x86/kvm/vmx/main.c index d0e1a5b5c915..45d6b5ad2da3 100644 --- a/arch/x86/kvm/vmx/main.c +++ b/arch/x86/kvm/vmx/main.c @@ -25,6 +25,8 @@ struct kvm_x86_ops vt_x86_ops __initdata =3D { =20 .hardware_enable =3D vmx_hardware_enable, .hardware_disable =3D vmx_hardware_disable, + .emergency_disable =3D vmx_emergency_disable, + .has_emulated_msr =3D vmx_has_emulated_msr, =20 .vm_size =3D sizeof(struct kvm_vmx), diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 0e3aaf520db2..7edbd4e5758e 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -754,7 +754,7 @@ static int kvm_cpu_vmxoff(void) return -EIO; } =20 -static void vmx_emergency_disable(void) +void vmx_emergency_disable(void) { int cpu =3D raw_smp_processor_id(); struct loaded_vmcs *v; @@ -8603,8 +8603,6 @@ static void __vmx_exit(void) { allow_smaller_maxphyaddr =3D false; =20 - cpu_emergency_unregister_virt_callback(vmx_emergency_disable); - vmx_cleanup_l1d_flush(); } =20 @@ -8651,8 +8649,6 @@ static int __init vmx_init(void) pi_init_cpu(cpu); } =20 - cpu_emergency_register_virt_callback(vmx_emergency_disable); - vmx_check_vmcs12_offsets(); =20 /* diff --git a/arch/x86/kvm/vmx/x86_ops.h b/arch/x86/kvm/vmx/x86_ops.h index 502704596c83..afddfe3747dd 100644 --- a/arch/x86/kvm/vmx/x86_ops.h +++ b/arch/x86/kvm/vmx/x86_ops.h @@ -15,6 +15,7 @@ void vmx_hardware_unsetup(void); int vmx_check_processor_compat(void); int vmx_hardware_enable(void); void vmx_hardware_disable(void); +void vmx_emergency_disable(void); int vmx_vm_init(struct kvm *kvm); void vmx_vm_destroy(struct kvm *kvm); int vmx_vcpu_precreate(struct kvm *kvm); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 4157602c964e..e4bdb42a9b00 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -12478,6 +12478,16 @@ void kvm_vcpu_deliver_sipi_vector(struct kvm_vcpu = *vcpu, u8 vector) } EXPORT_SYMBOL_GPL(kvm_vcpu_deliver_sipi_vector); =20 +void kvm_arch_enable_virtualization(void) +{ + cpu_emergency_register_virt_callback(kvm_x86_ops.emergency_disable); +} + +void kvm_arch_disable_virtualization(void) +{ + cpu_emergency_unregister_virt_callback(kvm_x86_ops.emergency_disable); +} + int kvm_arch_hardware_enable(void) { struct kvm *kvm; --=20 2.45.2.505.gda0bf45e8d-goog From nobody Thu Feb 12 19:05:42 2026 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.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 D675F1EEF9 for ; Sat, 8 Jun 2024 00:06:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805219; cv=none; b=FjOXW8s2tr/Ey7cXyHuuhUIJt7QptXzBVUdhRVUkFm/oi3ISNELZt3Kazn2+lNKr6FpmFxMeRNHOvkrOBQ/aB828L8Q/nnBins2w9GlN0MQ2DrGBvN+ld0obD890/tAjA///R30Q1HRQuUXtXq1CR2fToGvb8/3S2BUTAZbRKV8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717805219; c=relaxed/simple; bh=keNcwSMF4FkApxmQ2VK4QyKAfPOMI5FV7pwCXoqwCiw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=LIuYOkofv4S7vyfjJqOYjU8hLCFWmds7QlY2/vVN5cbv4KKbH/ZmJ63CBw59oTRi6ShgY3pSt87iJpKVhmQtv+vbBmRIzbAOug5NLYlHnbrn0itGEKhSlhy0F0vrfzHFjKgtVYRHZWtKHS1nboxxfG5Nr8HaC01D6G0K9iC4wM4= 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=teDdsSyT; arc=none smtp.client-ip=209.85.128.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="teDdsSyT" Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-62a23864df0so43321207b3.0 for ; Fri, 07 Jun 2024 17:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717805217; x=1718410017; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=BUjd1F/nSMBLgzmpYGS3K0aopy7os8Y5usHW0sJFCA4=; b=teDdsSyTCKURqYcoDOZTAbKcSPC/I+JFVsgAmD3RQIO8Tj1AZdWwdl0hlVq6qqIob+ AY6n+mdi2I2ElQK0VdRAPccYgLo/mTzynKGXdxvDHfg3A6qziHEkqtfHAuAJ0f4uJn59 HcjnrzFP4oQNd5ghpbOpQQyWIrfGlQfzHRhkLEh2T9EsjEB0D/gM0xY5hI5D87aQP+uE 9s9gTobOxYOfn8rspF/3XBPYDfh4nhlHrvI96NFCUrvWn8L/viy/LHOlpPeXFd5uy/35 gEpPWprrpdgn6XRtITCNsEiy1thtdHeoM+nAGRl+NJX/mRcPJaiPwWOOFGdAzd6Dj8dp 2CVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717805217; x=1718410017; h=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; bh=BUjd1F/nSMBLgzmpYGS3K0aopy7os8Y5usHW0sJFCA4=; b=GG9QLDnhFqXaizh+8awpI9AetL2ah5obzPosgy1OWKDp+DC3LJmAoMtpcnlBmrQLn7 mRNzOStQ8TJJgJJVbMm/1XBaigtmvr8QsKLDRzEllH6OUcX48WNoLmjdWBDUZwjRFK5y 4EEB/0FR5xf23Ss7GkBkYkJPTj0XOFK8Le0A4QZUO4Wiz+55sYmjF6i1+RnGZp6i8cd9 jrsqPjMV9U9JADhG+P/yZYgzNCsZM6hNwMVi3hD+L4m9JCqLO2OVGUfs2PjR8k9WnLiU +mcEqbwEX8TGxvIwtAwunxaktEq3+tfQS/g9cUo1180zyhLUzzUVqfuM+SqyfhWy07yC Kbug== X-Forwarded-Encrypted: i=1; AJvYcCWkX0oIXvMfxO7shRsSKbpRwbdu2WEpXb09rjxV0vmthv/7Ig+Zt+oRRCHuesCJs1WNJ3PXNdYvcFeu/xfVcW5KiwwL5YKSArl+FTOM X-Gm-Message-State: AOJu0YzSnE8+2mPhs6qcPlU6ItgnvxSG82iilVN3GMj1Xjz6aWzGalh+ Jo7kC9/zu4KY6DKnajNQuwYEMq/sU3D+yZCUZiwRLqamFpGdUiNjWKbGDyS3QfueWWFaKn4d4xP Oug== X-Google-Smtp-Source: AGHT+IGFTYtM41j5a9HMVGr+fnjy8o1+4kr7OtMPSRtzyUXfqtIDduBzI9p/ljDOhXVkr9L+HbkTuE5vn9I= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:6609:b0:627:a97a:3bcc with SMTP id 00721157ae682-62cd56e1bc9mr11028927b3.9.1717805216879; Fri, 07 Jun 2024 17:06:56 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 7 Jun 2024 17:06:39 -0700 In-Reply-To: <20240608000639.3295768-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: <20240608000639.3295768-1-seanjc@google.com> X-Mailer: git-send-email 2.45.2.505.gda0bf45e8d-goog Message-ID: <20240608000639.3295768-9-seanjc@google.com> Subject: [PATCH v3 8/8] KVM: Enable virtualization at load/initialization by default From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Gao , Kai Huang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Enable virtualization when KVM loads by default, as doing so avoids the potential runtime overhead associated with using the cpuhp framework to enabling virtualization on each CPU. Prior to commit 10474ae8945c ("KVM: Activate Virtualization On Demand"), KVM _unconditionally_ enabled virtualization during load, i.e. there's no fundamental reason KVM needs to dynamically toggle virtualization. These days, the only known argument for not enabling virtualization is to allow KVM to be autoloaded without blocking other out-of-tree hypervisors, and such use cases can simply change the module param, e.g. via command line. Note, the aforementioned commit also mentioned that enabling SVM (AMD's virtualization extensions) can result in "using invalid TLB entries". It's not clear whether the changelog was referring to a KVM bug, a CPU bug, or something else entirely. Regardless, leaving virtualization off by default is not a robust "fix", as any protection provided is lost the instant userspace creates the first VM. Suggested-by: Chao Gao Signed-off-by: Sean Christopherson Acked-by: Kai Huang Tested-by: Farrah Chen --- virt/kvm/kvm_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e20189a89a64..1440c0a7c3c3 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5495,7 +5495,7 @@ static struct miscdevice kvm_dev =3D { }; =20 #ifdef CONFIG_KVM_GENERIC_HARDWARE_ENABLING -static bool enable_virt_at_load; +static bool enable_virt_at_load =3D true; module_param(enable_virt_at_load, bool, 0444); =20 __visible bool kvm_rebooting; --=20 2.45.2.505.gda0bf45e8d-goog