Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1450802rwe; Thu, 1 Sep 2022 20:00:36 -0700 (PDT) X-Google-Smtp-Source: AA6agR4w7QIokx+93+HH5eHp10TLXKEAR0czfllICLcsOFkkeeWeXnRlHMfJ1khGJ8vb3fj4dExJ X-Received: by 2002:a17:902:e382:b0:173:36e4:ede6 with SMTP id g2-20020a170902e38200b0017336e4ede6mr32356283ple.139.1662087635908; Thu, 01 Sep 2022 20:00:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662087635; cv=none; d=google.com; s=arc-20160816; b=xsDiDwIo2IuTn6uPhbYRV0tiO0qhYLNP0PQiVsPO+XU4bt6uhi68DFC5iextzjHBO0 DYd55MVB7uDhVvgxXT+mw9PPeyo1kk8gAPjBOimpFT3qs63y5PN1A44DxN4lJqyqvmed of8pYA4NsirWKMG6AYD/c/HxNeAV7pIhd+7VIiQ9WQh/ypxKlYoH9kDmr68t/pGWynY/ 9fZ5/LYctxdlkAybrgchBn2YvTQafToS4wpqVxVRQv9KVApXnXWShX/6KWL0NYBIdzLz 8DDggX3UoUHcPavOXjUD4RiaZSojc21BaeoCjWfZmxHz//inMWvwZtHgJBFx7e5z8Por TYZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=W1G67C5df/S7/Oeur3326wY1QsCz4/GZ4EMGW5hl3Cc=; b=t89IhSyAxyRo49LAxXWADujXH6U2Okd1llQTYrebXVk41OupSCbDvc9CwcIPcws5co yqNLJ0Kcp+woTrTHxo6l3GXp9RG5Fa9BFviILZd44MfiDFbwzxG2EvE9ShJyutPFii+s oZwpBZex4HZOY7375uFL0pmYSNf/B8zs1C4FOuTvSHXc93ixAz7SEceSRGvAUXZ3lKm8 ay85JrvobBWGrO0mnhO4uHJyUkFRPley0E7cJFXZOfZ+aNPzmTIGMrymChGcn0IgQniW actf1Vag1P+6vp6A640h4KDQBahGVzT+ycG89Aw4HMjQJ2CORTJMZZt6hR1uaRnd7V6s gA7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ja/tChZ5"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j72-20020a638b4b000000b00430980f4c69si668195pge.872.2022.09.01.20.00.22; Thu, 01 Sep 2022 20:00:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ja/tChZ5"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235307AbiIBCTJ (ORCPT + 99 others); Thu, 1 Sep 2022 22:19:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232221AbiIBCSQ (ORCPT ); Thu, 1 Sep 2022 22:18:16 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B5312AA3EA; Thu, 1 Sep 2022 19:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662085095; x=1693621095; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=gFAtLr34ysA/aw7FXhfNAobiH3GISmSUXQkg/JKR0jI=; b=ja/tChZ50sfjsZ3lipW3jgOKgHA8uBK3yTv3RZNkt6EIJ/SH+HztzP0j 3+hw3dkS4hHrUwCuIe0MsYXU7KMaFtUrFFG1ZVUBfXOo1hDq2pgchpLAR 8qNAWdEGeXR5zAfyso5suwEp7dhNmMpuYf1/AkNCiASU9blBurYo7nZc8 6HJIjeDdj6XxPY9HUtFehtvP9b5D6kruAyGhC47ugKgt2hxwFHQogkrbN ryC+N3+KtvswaXv15J1HaCIr25kp/OE4z3OcxoqUBFsflWQw4kbfbiS2K EYDY3/GiPWBRPWZ2lR5F2NsiMIedv2rJN8Jrp0A4rD8FtXP+rUzfs7Awe w==; X-IronPort-AV: E=McAfee;i="6500,9779,10457"; a="297157847" X-IronPort-AV: E=Sophos;i="5.93,281,1654585200"; d="scan'208";a="297157847" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 19:18:15 -0700 X-IronPort-AV: E=Sophos;i="5.93,281,1654585200"; d="scan'208";a="608835628" Received: from ls.sc.intel.com (HELO localhost) ([143.183.96.54]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 19:18:15 -0700 From: isaku.yamahata@intel.com To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Sean Christopherson , Thomas Gleixner , Marc Zyngier , Will Deacon Cc: isaku.yamahata@intel.com, isaku.yamahata@gmail.com, Kai Huang , Chao Gao , Atish Patra , Shaokun Zhang , Qi Liu , John Garry , Daniel Lezcano , Huang Ying , Huacai Chen , Dave Hansen , Borislav Petkov Subject: [PATCH v3 10/22] KVM: Drop kvm_count_lock and instead protect kvm_usage_count with kvm_lock Date: Thu, 1 Sep 2022 19:17:45 -0700 Message-Id: <20212af31729ba27e29c3856b78975c199b5365c.1662084396.git.isaku.yamahata@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Isaku Yamahata Because kvm_count_lock unnecessarily complicates the KVM locking convention Drop kvm_count_lock and instead protect kvm_usage_count with kvm_lock for simplicity. Opportunistically add some comments on locking. Suggested-by: Sean Christopherson Signed-off-by: Isaku Yamahata --- Documentation/virt/kvm/locking.rst | 14 +++++------- virt/kvm/kvm_main.c | 34 ++++++++++++++++++++---------- 2 files changed, 28 insertions(+), 20 deletions(-) diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 845a561629f1..8957e32aa724 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -216,15 +216,11 @@ time it will be set using the Dirty tracking mechanism described above. :Type: mutex :Arch: any :Protects: - vm_list - -``kvm_count_lock`` -^^^^^^^^^^^^^^^^^^ - -:Type: raw_spinlock_t -:Arch: any -:Protects: - hardware virtualization enable/disable -:Comment: 'raw' because hardware enabling/disabling must be atomic /wrt - migration. + - kvm_usage_count + - hardware virtualization enable/disable +:Comment: Use cpus_read_lock() for hardware virtualization enable/disable + because hardware enabling/disabling must be atomic /wrt + migration. The lock order is cpus lock => kvm_lock. ``kvm->mn_invalidate_lock`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index fc55447c4dba..082d5dbc8d7f 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -100,7 +100,6 @@ EXPORT_SYMBOL_GPL(halt_poll_ns_shrink); */ DEFINE_MUTEX(kvm_lock); -static DEFINE_RAW_SPINLOCK(kvm_count_lock); LIST_HEAD(vm_list); static cpumask_var_t cpus_hardware_enabled; @@ -4996,6 +4995,8 @@ static void hardware_enable_nolock(void *caller_name) int cpu = raw_smp_processor_id(); int r; + WARN_ON_ONCE(preemptible()); + if (cpumask_test_cpu(cpu, cpus_hardware_enabled)) return; @@ -5019,7 +5020,7 @@ static int kvm_online_cpu(unsigned int cpu) if (ret) return ret; - raw_spin_lock(&kvm_count_lock); + mutex_lock(&kvm_lock); /* * Abort the CPU online process if hardware virtualization cannot * be enabled. Otherwise running VMs would encounter unrecoverable @@ -5034,7 +5035,7 @@ static int kvm_online_cpu(unsigned int cpu) ret = -EIO; } } - raw_spin_unlock(&kvm_count_lock); + mutex_unlock(&kvm_lock); return ret; } @@ -5042,6 +5043,8 @@ static void hardware_disable_nolock(void *junk) { int cpu = raw_smp_processor_id(); + WARN_ON_ONCE(preemptible()); + if (!cpumask_test_cpu(cpu, cpus_hardware_enabled)) return; cpumask_clear_cpu(cpu, cpus_hardware_enabled); @@ -5050,10 +5053,10 @@ static void hardware_disable_nolock(void *junk) static int kvm_offline_cpu(unsigned int cpu) { - raw_spin_lock(&kvm_count_lock); + mutex_lock(&kvm_lock); if (kvm_usage_count) hardware_disable_nolock(NULL); - raw_spin_unlock(&kvm_count_lock); + mutex_unlock(&kvm_lock); return 0; } @@ -5068,9 +5071,11 @@ static void hardware_disable_all_nolock(void) static void hardware_disable_all(void) { - raw_spin_lock(&kvm_count_lock); + cpus_read_lock(); + mutex_lock(&kvm_lock); hardware_disable_all_nolock(); - raw_spin_unlock(&kvm_count_lock); + mutex_unlock(&kvm_lock); + cpus_read_unlock(); } static int hardware_enable_all(void) @@ -5088,7 +5093,7 @@ static int hardware_enable_all(void) * Disable CPU hotplug to prevent this case from happening. */ cpus_read_lock(); - raw_spin_lock(&kvm_count_lock); + mutex_lock(&kvm_lock); kvm_usage_count++; if (kvm_usage_count == 1) { @@ -5101,7 +5106,7 @@ static int hardware_enable_all(void) } } - raw_spin_unlock(&kvm_count_lock); + mutex_unlock(&kvm_lock); cpus_read_unlock(); return r; @@ -5708,8 +5713,15 @@ static void kvm_init_debug(void) static int kvm_suspend(void) { - if (kvm_usage_count) + /* + * The caller ensures that CPU hotlug is disabled by + * cpu_hotplug_disable() and other CPUs are offlined. No need for + * locking. + */ + if (kvm_usage_count) { + lockdep_assert_not_held(&kvm_lock); hardware_disable_nolock(NULL); + } return 0; } @@ -5723,7 +5735,7 @@ static void kvm_resume(void) return; /* FIXME: disable KVM */ if (kvm_usage_count) { - lockdep_assert_not_held(&kvm_count_lock); + lockdep_assert_not_held(&kvm_lock); hardware_enable_nolock((void *)__func__); } } -- 2.25.1