From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A43DBC43217 for ; Thu, 10 Nov 2022 16:59:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230425AbiKJQ7G (ORCPT ); Thu, 10 Nov 2022 11:59:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230315AbiKJQ7D (ORCPT ); Thu, 10 Nov 2022 11:59:03 -0500 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92D9F11832 for ; Thu, 10 Nov 2022 08:59:01 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id k7so1879140pll.6 for ; Thu, 10 Nov 2022 08:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=++qaNnNL5OJX09F4SmymJbSNGTe4YNGKf8knlNeZLIM=; b=LnpIznW50UbJYIR0PEtWeJYNJ+5rH6MIlZozMzFMTwSQvTcP33ucW9c9lQSevvLDXI QyB5+yXhMZUDNlkwdSbDFjM7JR9S8ttOodJeLQApsp/g1X2g7iaiRMpztbbtLirGmHXP Ok5MPlCZ4tZXNzdoN/5EaAFNU5i/kMEU+Pj6UbsvHwVNko95a9bIdjWXiNhQrkyCMZcF 1gbXxHeTac5BLcvPalQHTWFwjbFrO0re69/ZDM4/c7ATiGknmYZEnSteDE0eFOsuiUGv o02wNWrUZNQBtGle02WgOsPhE6Inb5/XeEtyenAcor9m9bnEppDYL8UdqJt6p1agDB2o ED2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=++qaNnNL5OJX09F4SmymJbSNGTe4YNGKf8knlNeZLIM=; b=ekE+uwCCa1RplhDKZOVxd6t4IGoH10J3vz26DNPmzwuwkAmK1YDHZfB8uyoL93FeCT zXi3rkYLpNeSaC0yjCWNOyhz2jewwDakmAvEDeVWj6qkKGEVuNEwJuBvzsdZ8XHBoHX4 KvrY4WbNxwKQBVEku10REG9Nqdj6Z6HY1j78g3ouhp1P5TlLjWIg4YsUkROxHnHgEkwu TYRvNMfrmKmfAR/Y11vqaZ6QTmGD80xZM4uMeSp0deGNtgOLPrhPxC/FTlhkZW1kuIYd a0NsYdaSxdXp9fj6HkcCHhVCMipDiqcl+EPRLZffNJ7OIxuz/sdopXdcYhHna+BQBxr+ BOoA== X-Gm-Message-State: ANoB5pmw8NcdC0GHSJ036hHEjNDEe8MsZ0tvVfeXuNQMks7v6W0GxGIf LXgrnYJXEjmSxFLb6PUuZ6tiIA== X-Google-Smtp-Source: AA0mqf4HLI0425WgRwXjVOczy7lGJ1ZoFRhJMikRvyU6kmBBe6o5W1MVmVmeziJeqm75+QzM+47Lew== X-Received: by 2002:a17:902:6aca:b0:188:736c:befa with SMTP id i10-20020a1709026aca00b00188736cbefamr1100928plt.8.1668099540938; Thu, 10 Nov 2022 08:59:00 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id n63-20020a17090a5ac500b00200461cfa99sm3302123pji.11.2022.11.10.08.59.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Nov 2022 08:59:00 -0800 (PST) Date: Thu, 10 Nov 2022 16:58:56 +0000 From: Sean Christopherson To: "Huang, Kai" Cc: "farman@linux.ibm.com" , "frankja@linux.ibm.com" , "mjrosato@linux.ibm.com" , "vkuznets@redhat.com" , "chenhuacai@kernel.org" , "aou@eecs.berkeley.edu" , "palmer@dabbelt.com" , "paul.walmsley@sifive.com" , "maz@kernel.org" , "anup@brainfault.org" , "imbrenda@linux.ibm.com" , "pbonzini@redhat.com" , "borntraeger@linux.ibm.com" , "aleksandar.qemu.devel@gmail.com" , "kvm@vger.kernel.org" , "atishp@atishpatra.org" , "farosas@linux.ibm.com" , "david@redhat.com" , "Yao, Yuan" , "mpe@ellerman.id.au" , "alexandru.elisei@arm.com" , "linux-s390@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "Yamahata, Isaku" , "kvmarm@lists.linux.dev" , "james.morse@arm.com" , "kvm-riscv@lists.infradead.org" , "suzuki.poulose@arm.com" , "linuxppc-dev@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mips@vger.kernel.org" , "Gao, Chao" , "oliver.upton@linux.dev" , "kvmarm@lists.cs.columbia.edu" , "linux-riscv@lists.infradead.org" Subject: Re: [PATCH 38/44] KVM: Disable CPU hotplug during hardware enabling Message-ID: References: <20221102231911.3107438-1-seanjc@google.com> <20221102231911.3107438-39-seanjc@google.com> <88e920944de70e7d69a98f74005b49c59b5aaa3b.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 10, 2022, Huang, Kai wrote: > On Thu, 2022-11-10 at 01:33 +0000, Huang, Kai wrote: > > > @@ -9283,7 +9283,13 @@ static int > > > kvm_x86_check_processor_compatibility(struct kvm_x86_init_ops *ops) > > >   int cpu = smp_processor_id(); > > >   struct cpuinfo_x86 *c = &cpu_data(cpu); > > >   > > > - WARN_ON(!irqs_disabled()); > > > + /* > > > + * Compatibility checks are done when loading KVM and when enabling > > > + * hardware, e.g. during CPU hotplug, to ensure all online CPUs are > > > + * compatible, i.e. KVM should never perform a compatibility check > > > on > > > + * an offline CPU. > > > + */ > > > + WARN_ON(!irqs_disabled() && cpu_active(cpu)); > > >   > > > > Also, the logic of: > > > > !irqs_disabled() && cpu_active(cpu) > > > > is quite weird. > > > > The original "WARN(!irqs_disabled())" is reasonable because in STARTING > > section > > the IRQ is indeed disabled. > > > > But this doesn't make sense anymore after we move to ONLINE section, in which > > IRQ has already been enabled (see start_secondary()).  IIUC the WARN_ON() > > doesn't get exploded is purely because there's an additional cpu_active(cpu) > > check. > > > > So, a more reasonable check should be something like: > > > > WARN_ON(irqs_disabled() || cpu_active(cpu) || !cpu_online(cpu)); > > > > Or we can simply do: > > > > WARN_ON(!cpu_online(cpu) || cpu_active(cpu)); > > > > (because I don't know whether it's possible IRQ can somehow get disabled in > > ONLINE section). > > > > Btw above is purely based on code analysis, but I haven't done any test. > > Hmm.. I wasn't thinking thoroughly. I forgot CPU compatibility check also > happens on all online cpus when loading KVM. For this case, IRQ is disabled and > cpu_active() is true. For the hotplug case, IRQ is enabled but cpu_active() is > false. > > So WARN_ON(!irqs_disabled() && cpu_active(cpu)) looks reasonable. Sorry for the > noise. Just needed some time to connect the comment with the code. No worries, more than once while working through this code, I've considered setting up one of those evidence boards from the movies with string and push pins to help connect all the dots.