From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Fri, 11 Nov 2022 00:06:08 +0000 Subject: [PATCH 36/44] KVM: x86: Do compatibility checks when onlining CPU In-Reply-To: <20221104071819.GD1063309@ls.amr.corp.intel.com> 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> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. 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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FDACC43217 for ; Fri, 11 Nov 2022 00:06:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 79BA84BAA9; Thu, 10 Nov 2022 19:06:20 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ65oi90N3bX; Thu, 10 Nov 2022 19:06:15 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 925ED4BACC; Thu, 10 Nov 2022 19:06:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0CF5C4BAC7 for ; Thu, 10 Nov 2022 19:06:15 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTvqMJts5uhn for ; Thu, 10 Nov 2022 19:06:13 -0500 (EST) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 9AA694BAA9 for ; Thu, 10 Nov 2022 19:06:13 -0500 (EST) Received: by mail-pf1-f171.google.com with SMTP id k15so3503212pfg.2 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=j6OXVuaumtuGuQVwSQhWEu4ojlJdrbOVl6IeYha4bQTu0PyR9l9mrrIdihpPSKwbOD SasYVHcg0uC7Z4F54y3HIpZKuPY+2hFwRaUTxBJjT9UgKuU2XWPmXtsOiK1puwDGuDkZ ZMnrCirobwlRdpocayCHURxrW3tAERKNMCAdAORq7wWWYFQkCPHtqF4D+Y+vN1XFFz1F 57bAFcG19g93yRm8+njBjfl9GLLaeoIKT8f2FTiFY1YWx/2UITNKIgWeC4yRIbwGdvoL l+A41sBpoD4wF2Rt3BR4akIcvFn9xTOkLpxI8VWnIGsvxB+ItA8+dc6cVaSnn8w7pxgA tsWA== X-Gm-Message-State: ACrzQf0drCUjAMG6tGv7CFuZapmuo0NnCxlQCWoLh+5j1B6Y8qYsMB+4 gBJ7i58LKe8Z+3ZMTqgmEgV3kQ== 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 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-Disposition: inline In-Reply-To: <20221104071819.GD1063309@ls.amr.corp.intel.com> Cc: Matthew Rosato , David Hildenbrand , Yuan Yao , Paul Walmsley , linux-kernel@vger.kernel.org, Michael Ellerman , linux-riscv@lists.infradead.org, Claudio Imbrenda , kvmarm@lists.cs.columbia.edu, linux-s390@vger.kernel.org, Janosch Frank , Marc Zyngier , Huacai Chen , Aleksandar Markovic , Christian Borntraeger , Chao Gao , Eric Farman , Albert Ou , kvm@vger.kernel.org, Atish Patra , kvmarm@lists.linux.dev, Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Isaku Yamahata , Fabiano Rosas , linux-mips@vger.kernel.org, Palmer Dabbelt , kvm-riscv@lists.infradead.org, Paolo Bonzini , Vitaly Kuznetsov , linuxppc-dev@lists.ozlabs.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (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 381B37E for ; Fri, 11 Nov 2022 00:06:13 +0000 (UTC) Received: by mail-pf1-f179.google.com with SMTP id y13so3481019pfp.7 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=HnZNy2vbprncLsudSoTf+rtS/EiRqKez9SIBkpN2JC8c4ZNgjMP6/NfaTwW7paBT7R wgTEoeZAw2RI0EcR4OzS1jTkgwwPeGfiKfJKOs5XFyOkBialhPE6HOliH5rmlGF6Gu8H /Tp5pqR/LK9eCaDPpufFO0BS9/10dMjRzyPtcy8hpiy2UOBvCtvdiPn8y1ag+vKIuKaT HgvO4J4T5X0EbOf7BoXEApppmH+UeHg9AO2q7gsl82oiNJolYkUXgUxT9VABkYl/8lO0 0FouhhNdompgonKGsCOIyaR3VxdH6tJ1wGFHTNJUOSkAS8JBL7s1MDG5+j3YWogT5eL8 fo1w== X-Gm-Message-State: ACrzQf2qs2yrryu3a6t24tyHUc2Vx3Y0GUF131msa5ugnw4tfqcoTes7 lDFiiy7naMQK09gQzpxf0vcj8Q== 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> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221104071819.GD1063309@ls.amr.corp.intel.com> Message-ID: <20221111000608.mKXPvVHnp2cncH9AtfeIFUbYW0ayZ0CtkFFXW4c1lCQ@z> 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. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AB47FC433FE for ; Fri, 11 Nov 2022 00:06:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=sPYWlWy/rSLyh3L7ETcgGNRS/PoHbSEJb4bkXxoAnf0=; b=VQ01LVnaskONu7 TXtirN7msU5Pv/g4YGR9aX62sw+Rli3HHC/doaU5aAFtknZdtKJn4oJ2ROBTOWtHvziFGpfWetOdm Kzb+HyBzpjc9HnvrjKhGpLW6E3D7vfFymj5Kxc7P2b8t/QlBfjAhrxRwnN37K+vNiykJHA+rP+TRq PLv2hXKTBEvzPMklHbM6oK/K70iPUC7ZTTIXVYomtJub3kzUUbfNq0bvHqbbvVW4AbC2Raq+//lss YxKZ9fOP/ORydQCxGCloBlGpbPWMZ5U6hLTg5RrR8HWJdnyhoX4iGng4ItDody4hGgoIa3XQ4/qLE HmTRGoDxRPjxETB04IJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1otHYn-00BQnx-A9; Fri, 11 Nov 2022 00:06:17 +0000 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1otHYl-00BQmu-9P for linux-riscv@lists.infradead.org; Fri, 11 Nov 2022 00:06:16 +0000 Received: by mail-pf1-x42a.google.com with SMTP id 140so2017634pfz.6 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=LITsUxkW2eG00oqK+VNek+4pkbGzWHUZj1aa/FENoqPQKzMEb1AGuPqD2WyVUhzc5s yepnq5A4l1WzAFuds1g+ZFoHYQe1NfgZ/jOk6JdC7Enkxz7aJtK2wZV56RtZ2WYuxm03 4rijrc6nNxwkMh+J7Qa6PQPhUwVqAff5Qu7WkWdoX6oA2Ckgjw9GASQUCPpj7V8oFfmV aEZxiq1SLQlfk28D9JTPzu+RX+Z4Bo2B0EWNy+0LK7Nh7UI7L/s/V1i9D9mR4eLc3Wly UF5euGNRfrhU/0HjYvbQ2m017MMXJMxtGdzYuID1v9ik1wMBaodB4E+jgDOhpiH9B9i0 s8gg== X-Gm-Message-State: ACrzQf0qmma1S0btOgpEtyZdz+6/k++QnhPepbYmBUOYGqNLQ04R7nK4 TeOrLMF+QMtWEbsw+vxF9n15Aw== 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-Disposition: inline In-Reply-To: <20221104071819.GD1063309@ls.amr.corp.intel.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221110_160615_353879_1F717DBB X-CRM114-Status: GOOD ( 23.01 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5CE62C433FE for ; Fri, 11 Nov 2022 00:07:14 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4N7fCN4Qjrz3f3Q for ; Fri, 11 Nov 2022 11:07:12 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=hNVPv+ey; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=google.com (client-ip=2607:f8b0:4864:20::42d; helo=mail-pf1-x42d.google.com; envelope-from=seanjc@google.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=hNVPv+ey; dkim-atps=neutral Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4N7fBH6hRKz3cF0 for ; Fri, 11 Nov 2022 11:06:14 +1100 (AEDT) Received: by mail-pf1-x42d.google.com with SMTP id b29so3453197pfp.13 for ; Thu, 10 Nov 2022 16:06:14 -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=N7IAoT/CF5HoJ3o1QAh3hUwWudcBcWYDEz+9q2E0PnJ3SG6iz/yrpohf1IXCHU0FvZ R678COyX3uFI44KaeTyXb/3H+k4FU4NhibLfYxgPf7Ob3RdJ/aw1A9sAF7hmEp4Dbs7u N9SHE1gplsPhDqgR3bcyKPdf42/BPcvNTUDzGhneiwSlV+jODpA1F+jCyxCjYHuGaBoT QVIANsn/YjzXY6tRO4kK9DXArzXTb03JfaUXzJlpAziWMlDyq2c8iQ2rOJCw0angEf4r SesyUNFk70Lb4kg5pZXxqmWeum0WBSXsyTMee3YfOsUjKUxVin1hUkjxLFnXQtFDsTtd BBsg== X-Gm-Message-State: ACrzQf3ifL3pykUUBRrdHS4pIkJjF5d0AMsLvpHPUhd1fguIh1DELPAu lcaKq0yzU2B84BKX0LucjvtHOQ== 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 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> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Matthew Rosato , David Hildenbrand , Yuan Yao , Paul Walmsley , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Claudio Imbrenda , kvmarm@lists.cs.columbia.edu, linux-s390@vger.kernel.org, Janosch Frank , Marc Zyngier , Huacai Chen , Aleksandar Markovic , James Morse , Christian Borntraeger , Chao Gao , Eric Farman , Albert Ou , Suzuki K Poulose , kvm@vger.kernel.org, Atish Patra , kvmarm@lists.linux.dev, Thomas Gleixner , Alexandru Elisei , linux-arm-kernel@lists.infradead.org, Isaku Yamahata , Fabiano Rosas , linux-mips@vger.kernel.org, Oliver Upton , Palmer Dabbelt , kvm-riscv@lists.infradead.org, Anup Patel , Paolo Bonzini , Vitaly Kuznetsov , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5F316C433FE for ; Fri, 11 Nov 2022 00:07:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=I3dF4YjllFvGGKRFiVMX7mxXo4R6MjfbNhMayTf6Dzo=; b=lfaZXozW+UlySL r/edcHYr2sSRlQwZ9p8P81I6++7b5YQGAR9kM74WvmeTwT+ugxMwyI5fhS6wc1l9GZpdDTNi/Wv0s Y39jbRuMv31WEWRlc7KK3lTBELyXjItf+ADszI5qugSydUUZBByT91wZg5Wybjc5quY1MDXwN6P1+ CO1ki/EWhiZs10KBjTitaVCKT47BblYudIMhmT+c/zCypENKVBVQuqYwAsRqZ4gdB5UfGultPGKWV jTNvMiKNL/awGTDOrQ3epZW+X+QJZLiRNLGeEds8Ak+mbWeQ+yB91sZfsymjnIl5I6bFf6EmIgzds AY7sz+qoGukCBUK3dypQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1otHYq-00BQpC-CJ; Fri, 11 Nov 2022 00:06:20 +0000 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1otHYm-00BQms-JX for linux-arm-kernel@lists.infradead.org; Fri, 11 Nov 2022 00:06:17 +0000 Received: by mail-pf1-x436.google.com with SMTP id 130so3473525pfu.8 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=i68MOTTN32mYAYxVnZN/6g1dmHljZkpqGtJRssAsXob7+Dc+PRopU6A5ohA3wh07NO HLcmZpW7nbxjodIJeX3lu5KnDOa39TbkupxjG00ozyo8wZ+d4raDCgBs19Ebc+rMos7D Slal6q8TISqFZstsydbJC8AITwH/g6GFSWkb3oFDPAuKtSYRaRZq+d92c80b1qVChHwL 8ANkNJcIW1wfcxbG5+dBh/xPrUdnA5sftp86kRPWdKBq7oW6kvF9ICXPPX0akooR3u/4 cxf9S2nvFShtMqwk7l6GxoSYFwcAEb4pHUW7eu52UWZezTTJmiJu3m2sZPRotGgMGf/p Q31w== X-Gm-Message-State: ACrzQf0rveDdU40nvWO2uONX+1RYwDRNi2xUjmbaBhK1ZRLyzS/zBDIC RIgGhjaOyw3g+vwGN7Ly2pCZxg== 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-Disposition: inline In-Reply-To: <20221104071819.GD1063309@ls.amr.corp.intel.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221110_160616_648503_6379B33A X-CRM114-Status: GOOD ( 24.62 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel