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 9E082C43334 for ; Tue, 28 Jun 2022 23:41:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230044AbiF1Xlc (ORCPT ); Tue, 28 Jun 2022 19:41:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbiF1Xlb (ORCPT ); Tue, 28 Jun 2022 19:41:31 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DCDA33A0C; Tue, 28 Jun 2022 16:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656459691; x=1687995691; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=7b5j1MEXlH7DEeLwlQG8w1yR1W0RygEbHO/Yh+JB6uY=; b=SNSbXqNCojdPqF85vurSZGZ0CAVuoteP7I9x5cdfUq1huUxlnBrlFfWA 7sNhjhVv9REreO3gYNhOxy0uNNMK38wxVtyvHdRg0CDj+Hi6Pr/pMgRQO 5OaMIOXpIx2DacxYoJOlNuuWYX3IbqRINchvqh0w0pN7g5hHkjTdlqpyf aTKKIQSaICuM5r1K9zNSgSB3qHNxEz/IreMdGXx1NZ3OFoL4QY3QbFXyn VTb5FFVvSev9tyfVDmLoIy23E+6+3Ggxu8oLp94YzZWID7zQhnkhVgycR l94TKpg0EjeoSTnufCgwT899uf1xrC7yr265reuFtzE+x2XLpMkvccdqa w==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="368189569" X-IronPort-AV: E=Sophos;i="5.92,230,1650956400"; d="scan'208";a="368189569" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 16:41:30 -0700 X-IronPort-AV: E=Sophos;i="5.92,230,1650956400"; d="scan'208";a="588047790" Received: from gregantx-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.212.119.76]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 16:41:24 -0700 Message-ID: Subject: Re: [PATCH v5 02/22] cc_platform: Add new attribute to prevent ACPI CPU hotplug From: Kai Huang To: "Rafael J. Wysocki" Cc: Igor Mammedov , Linux Kernel Mailing List , kvm-devel , ACPI Devel Maling List , Sean Christopherson , Paolo Bonzini , Dave Hansen , Len Brown , Tony Luck , Rafael Wysocki , Reinette Chatre , Dan Williams , Peter Zijlstra , Andi Kleen , "Kirill A. Shutemov" , Kuppuswamy Sathyanarayanan , isaku.yamahata@intel.com, Tom Lendacky , Tianyu.Lan@microsoft.com, Randy Dunlap , "Jason A. Donenfeld" , Juri Lelli , Mark Rutland , Frederic Weisbecker , Yue Haibing , dongli.zhang@oracle.com Date: Wed, 29 Jun 2022 11:41:22 +1200 In-Reply-To: References: <20220627100155.71a7b34c@redhat.com> <2b676b19db423b995a21c7f215ed117c345c60d9.camel@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.2 (3.44.2-1.fc36) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 2022-06-28 at 19:33 +0200, Rafael J. Wysocki wrote: > > Hi Rafael, > >=20 > > I am not sure I got what you mean by "This will affect initialization, = not > > just > > hotplug AFAICS", could you elaborate a little bit?=C2=A0 Thanks. >=20 > So acpi_processor_add() is called for CPUs that are already present at > init time, not just for the hot-added ones. >=20 > One of the things it does is to associate an ACPI companion with the give= n > CPU. >=20 > Don't you need that to happen? You are right. I did test again and yes it was also called after boot-time present cpus are up (after smp_init()). I didn't check this carefully at m= y previous test. Thanks for catching. --=20 Thanks, -Kai