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;
Date:   Tue, 23 Aug 2022 10:26:09 +0800
From:   Chao Gao <chao.gao@intel.com>
To:     <isaku.yamahata@intel.com>
CC:     <kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <isaku.yamahata@gmail.com>, Paolo Bonzini <pbonzini@redhat.com>,
        "Sean Christopherson" <seanjc@google.com>,
        Kai Huang <kai.huang@intel.com>,
        "Will Deacon" <will@kernel.org>
Subject: Re: [RFC PATCH 03/18] KVM: Drop kvm_count_lock and instead protect
 kvm_usage_count with kvm_lock
Message-ID: <YwQ6wTmbja4h2TYZ@gao-cwp>
References: <cover.1660974106.git.isaku.yamahata@intel.com>
 <6b07c02dd361f834fea442eb8dae53f23618f983.1660974106.git.isaku.yamahata@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6b07c02dd361f834fea442eb8dae53f23618f983.1660974106.git.isaku.yamahata@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zvwZhAeqO+ZGnTk3t3yD+xFjZAEcoEOrOM2W/+1GlrVsCoZBXZRjdg2gc6EF?=
 =?us-ascii?Q?CEFEY5MGLG7QUNmVmorqFxtrkBv1OLwKQ4sSWL0wQfClkwmb5SLazXbEwq3h?=
 =?us-ascii?Q?HV6J6AUEtqD4+Q4JQocsrd65uwxxTwzjTT79swTNZDF05E3OWuGb8hwDFoKk?=
 =?us-ascii?Q?awBg+ahA2hoyKhwiF6uuSA+VeI3d+W6wjnaLjz9V4/lXULKnaVCVRzcFkJjo?=
 =?us-ascii?Q?hUnIYAqYXWGHFrUZz+08NQy1qgIhlEHrsIGkvYqA/EsTaz3XdRsAL9+Jo8/K?=
 =?us-ascii?Q?n6CNBwFHYcOurnTrAbvduKkgSxPtdNemM+J8t0LP6UarLdGT4VuJxZXNrIbW?=
 =?us-ascii?Q?0AYVAlYdSFJjX58M9+/9vyZpEPNnODg6BjxE0uPrJzVodAZa50iHxiUleN6g?=
 =?us-ascii?Q?HYt2bhWe03bUymwllyifW2bDPXaEbvZtCzEeQScM/UuhAgNBNs8SN1zmN6sj?=
 =?us-ascii?Q?BEyGr/lW206Y0Fh7bgYLlwZXRa/V8wXc5d4ad+Rzk6TyvtOHxJQtj9W/IVk/?=
 =?us-ascii?Q?GsMCOGeRfu5lukg2Dkkgp+kN2/cZSY6jfUULVklj6KkpC32di1ZNTsxJFL7X?=
 =?us-ascii?Q?VnBo9KZ5t+bW5Jqf0jyq2xoAjZNPI/7Nqd4r9JRs/g20XCn9iUKKsvTamCQ6?=
 =?us-ascii?Q?90ULDtVpRkl02QKPEQuXvbVJp+uA+N6h0/gXSzHpuBHDdeNKr2dzzsHTPVy2?=
 =?us-ascii?Q?lSyjv18G9w9qmVH+xaJn1uJPMTR1oMTdU3tULpri50nzrV0W8Y/nAVQKkuaB?=
 =?us-ascii?Q?VnCmC7kdif0kLPuFK/WzUvpMBOMqNF2ETBZ0D+VEsQYwz2y6eWLSAAOvbz09?=
 =?us-ascii?Q?uFEOOuDx2qTj7UFafpSDK36KlxD1XQ+wvtl+3R8lDIPNqfVTTtcSqqBgN79E?=
 =?us-ascii?Q?5dXolqkUHpMfPgaJCnKJ4KvYI7VSyYYfaW4+gmTFfnqOamSIb1Zw7YjvsUVf?=
 =?us-ascii?Q?By8Fs9AJaz5UmUt+9nwwioTean0CPyz+MWvcv/6MSTzvBQgljOz4//ZK5Q33?=
 =?us-ascii?Q?yVmYCP7w2jYP7iv8cJVyHPj6h8VA391V6wZ47o9ETJHmuGipg4aPspjDLMzs?=
 =?us-ascii?Q?CQ8FauWbgphWOlH86ImDNH90XdrlFEqflKXxUD7IHSLMPF2aguWGpPnQVPh8?=
 =?us-ascii?Q?MV6Hn2PPmA07m0OoCSU8cUvv1y4436mGoVY6BmMRKmcWvK5yzQiJOlaUZz8+?=
 =?us-ascii?Q?/U4+2531Xvmoi0m2YjHOWhto5IWVeYMTBnDPUoV+A89iKD/3R6SqOTn8xENY?=
 =?us-ascii?Q?AS3m/fhyIW4pDm4mQ108o9I3Z/OyfYM9dyI4YxGSEBQgoz/60faRV2aF5E+4?=
 =?us-ascii?Q?umO6XH9LD0r4aEwt9Z6una+BqmqFijOpu1iuMPJ0q1IkZx8HrZ2AbLUsD/oc?=
 =?us-ascii?Q?esU6UhT2ghZdmWL1Jcxa0SLnXi55gN9Ztu1GSqVMQSJns++d40wJVwXsHvE7?=
 =?us-ascii?Q?X2p7P/ZhvCtRG7K01pZ+RZHmOxSN6O3Ac1UuL/ckdhWIGFLfm32zFkxlmcqT?=
 =?us-ascii?Q?wbhddngXjdX8nseDZQ2Z8p71IkCiMAS4ODT2XGddbF6RJ5ccd0Nw8Et6+48i?=
 =?us-ascii?Q?vFp5IBT/xyJaP5wZX4ZlND/EO+nyugdrNC0uYIRH?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a281d1d0-f9a6-4a80-06b5-08da84aedafa
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2221.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2022 02:26:16.0903
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: b35lLoTD/B07WvvBmQIzbIsrD9twiGUAeaP+Q/GBoShuI/+5FavPGwM3yrFxjG5AD75Pzn0mUqJlFWJF6paDww==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3390
X-OriginatorOrg: intel.com
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,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Aug 19, 2022 at 11:00:09PM -0700, isaku.yamahata@intel.com wrote:
>From: Isaku Yamahata <isaku.yamahata@intel.com>
>
>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 <seanjc@google.com>
>Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
>---
> static cpumask_var_t cpus_hardware_enabled;
>@@ -4999,6 +4998,8 @@ static void hardware_enable_nolock(void *junk)
> 	int cpu = raw_smp_processor_id();
> 	int r;
> 
>+	WARN_ON_ONCE(preemptible());
>+
> 	if (cpumask_test_cpu(cpu, cpus_hardware_enabled))
> 		return;
> 
>@@ -5015,10 +5016,10 @@ static void hardware_enable_nolock(void *junk)
> 
> static int kvm_starting_cpu(unsigned int cpu)
> {
>-	raw_spin_lock(&kvm_count_lock);
>+	mutex_lock(&kvm_lock);

kvm_starting_cpu() is called with interrupt disabled. So we cannot use
sleeping locks (e.g., mutex) here.