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 462A7C433FE for ; Fri, 11 Nov 2022 00:06:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229907AbiKKAGO (ORCPT ); Thu, 10 Nov 2022 19:06:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229579AbiKKAGN (ORCPT ); Thu, 10 Nov 2022 19:06:13 -0500 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1CCDD5C77C for ; Thu, 10 Nov 2022 16:06:13 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id y203so3494557pfb.4 for ; Thu, 10 Nov 2022 16:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=sXQg6m0KDTXTm2nqz+lTg6WMBvdzJA0Ss4aaQqsqfi0=; b=hNVPv+ey8HIvOZmC+WAnWIG8OYAeSlZS0xPLzYhDCZmnArotz5Y/nhfn9r9c8PCEFe E8mVjVIva+def9PHp762BmRXmUoK5jg3heR3NAusrpN5STPSFfkervClje0NQa5CwXrE HdlsTtSUM+MPo4+vdGUA38aqr644tAa7P5bI3VxUrx5hCBiuVMLzUakeu0v8EjWAOK7v BgVrNZDyAWChq0qRi87Yhdn0EcEzkTu6Ae/6zTz8SPVNgwEGA83vKScQ/P1+h2fj3QJH Ic9NMyWV4IhkYFZTb5wG6PyKY3kSFDqOOs7F1TgAuJpwI7fBOge9ep4GrU+eZD7ML8Bk 8lbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to: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=sXQg6m0KDTXTm2nqz+lTg6WMBvdzJA0Ss4aaQqsqfi0=; b=olNcktD8l00Dim6dAXkunMwrx1kTENunBaDg1kY1smMd8zB4IDYAnx9ff+9Zbr8HxY gmR34+WvViCMWkl5o2XJcYXxZ3FDb4lUXp0BdjquowqEyX80Zv7FuISyfPPJtzw3Ju37 2ng2P4uiSSwcD90ujgkOFQHtJIatWHaSD6TYEBd7/pH5S0weeBu7QnppO32K5IO1o9ga flWzBoYBkmnm3bl2P82KnC8pCfpt4zS3BIomER7ysYoxXcnR1l2vZEGUgFP1Rg+e29Cf 7YmVN4b9evIp2x/an80/Kt7BrExq8l8rgS6SFcOme7+6mpaZVoHxXE4ZMliy0vFaxJW7 YaLw== X-Gm-Message-State: ACrzQf3KzO0VSk963SAj97Xkef+oL6a72Ew0nt1W2/PI7L2A4QMkWIMf z2J0eL34Zn5teuF+u3I+FkI9cg== X-Google-Smtp-Source: AMsMyM4gD1W2r9wxYtObzCBR9GM6UAk6Hoer15K7R44TK7byNmqvji7Uiit5OvUTQRObzAPBYqhIPw== X-Received: by 2002:a05:6a00:bef:b0:56e:3a98:1089 with SMTP id x47-20020a056a000bef00b0056e3a981089mr3906306pfu.38.1668125172489; Thu, 10 Nov 2022 16:06:12 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id s18-20020a170903215200b00186a6b6350esm234146ple.268.2022.11.10.16.06.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Nov 2022 16:06:12 -0800 (PST) Date: Fri, 11 Nov 2022 00:06:08 +0000 From: Sean Christopherson To: Isaku Yamahata Cc: Paolo Bonzini , Marc Zyngier , Huacai Chen , Aleksandar Markovic , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Matthew Rosato , Eric Farman , Vitaly Kuznetsov , James Morse , Alexandru Elisei , Suzuki K Poulose , Oliver Upton , Atish Patra , David Hildenbrand , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, Isaku Yamahata , Fabiano Rosas , Michael Ellerman , Chao Gao , Thomas Gleixner , Yuan Yao Subject: Re: [PATCH 36/44] KVM: x86: Do compatibility checks when onlining CPU Message-ID: References: <20221102231911.3107438-1-seanjc@google.com> <20221102231911.3107438-37-seanjc@google.com> <20221103210402.GB1063309@ls.amr.corp.intel.com> <20221104071819.GD1063309@ls.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221104071819.GD1063309@ls.amr.corp.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Fri, Nov 04, 2022, Isaku Yamahata wrote: > On Thu, Nov 03, 2022 at 10:34:10PM +0000, > Sean Christopherson wrote: > > > On Thu, Nov 03, 2022, Isaku Yamahata wrote: > > > On Wed, Nov 02, 2022 at 11:19:03PM +0000, > > > Sean Christopherson wrote: > > > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > > > > index f223c845ed6e..c99222b71fcc 100644 > > > > --- a/arch/x86/include/asm/kvm_host.h > > > > +++ b/arch/x86/include/asm/kvm_host.h > > > > @@ -1666,7 +1666,7 @@ struct kvm_x86_nested_ops { > > > > }; > > > > > > > > struct kvm_x86_init_ops { > > > > - int (*check_processor_compatibility)(void); > > > > + int (*check_processor_compatibility)(int cpu); > > > > > > Is this cpu argument used only for error message to include cpu number > > > with avoiding repeating raw_smp_processor_id() in pr_err()? > > > > Yep. > > > > > The actual check is done on the current executing cpu. > > > > > > If cpu != raw_smp_processor_id(), cpu is wrong. Although the function is called > > > in non-preemptive context, it's a bit confusing. So voting to remove it and > > > to use. > > > > What if I rename the param is this_cpu? I 100% agree the argument is confusing > > as-is, but forcing all the helpers to manually grab the cpu is quite annoying. > > Makes sense. Let's settle it with this_cpu. Finally got to actually change the code, and am not a fan of passing "this_cpu" everywhere. It's not terrible, but it's not clearly better than just grabbing the CPU on-demand. And while manually grabbing the CPU in the helpers is annoying, in at least two cases the pain is just shifted to the caller. I'm going with your original suggestion of just grabbing raw_smp_processor_id() in the helpers that print the error message.