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 B816EC00140 for ; Wed, 10 Aug 2022 21:57:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233013AbiHJV5V (ORCPT ); Wed, 10 Aug 2022 17:57:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232785AbiHJV5S (ORCPT ); Wed, 10 Aug 2022 17:57:18 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E46781B28 for ; Wed, 10 Aug 2022 14:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660168638; x=1691704638; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=zWL7knpSxfOLVTuPGGUfO9icTmdPu1AKSWoBLlI/HPY=; b=hlUDhOzmpqtnelNnGFlg9kIxsJ0lykccUUSQpSbDcEplXK1InKGR9m6w mx1BzcRUUMskySN0w7BzEhNMCWj2dszlJfSVTd0YfcLM/MWJXDyA27WfJ wn40sC7rBQH1W3zqwVKc/kPrXDBrBBTIBszBVXL1Nh3/DASCqW/8g6W1V zJs3JWCse/teN5zpP31J/NB9Qc6geGv4p0dyH8jBgQsmonNLEsBmPx0IC +NvA7LAe+mvBFQ3phpIB5pydIMR5oqVCnRlTlwaJM6Hh+w2BBPjEZudEO y/zrw2hO4NN9ODj8TmCFUHfezoYLr5oLq/JIehfSkVYhzveybo/BURidd w==; X-IronPort-AV: E=McAfee;i="6400,9594,10435"; a="352939937" X-IronPort-AV: E=Sophos;i="5.93,228,1654585200"; d="scan'208";a="352939937" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2022 14:57:18 -0700 X-IronPort-AV: E=Sophos;i="5.93,228,1654585200"; d="scan'208";a="781381887" Received: from snedunga-mobl2.amr.corp.intel.com (HELO [10.212.234.47]) ([10.212.234.47]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2022 14:57:17 -0700 Message-ID: Date: Wed, 10 Aug 2022 14:57:19 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] x86/apic: Don't disable x2APIC if locked Content-Language: en-US To: Daniel Sneddon , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "Shutemov, Kirill" Cc: "H. Peter Anvin" , linux-kernel@vger.kernel.org, "Gomez Iglesias, Antonio" , Pawan Gupta References: <20220809234000.783284-1-daniel.sneddon@linux.intel.com> <238ea612-5a25-9323-b31f-0a14493db2f7@linux.intel.com> <341ea6e9-d8f3-ee7a-6794-67408abbf047@linux.intel.com> <2446fb33-9c5c-642a-797e-4e93345adb82@linux.intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/10/22 13:29, Daniel Sneddon wrote: > On 8/10/22 13:06, Daniel Sneddon wrote: >> I could add a blurb to the >> documentation where nox2apic is defined as a parameter as well. > While I'm at it, I'm thinking of adding something where CONFIG_X86_X2APIC is > defined in kconfig. I'll put in a blurb about selecting N on SPR systems could > prevent you from booting due to the lock. Please don't make it _too_ specific. This is, after all, new architecture that is presumably going to be in place long after we all forget what SPR is. Good Kconfig text would probably be something along the lines of: Some ~2022 and later systems are locked into x2APIC mode and can not fall back to the legacy APIC modes. They will be unable to boot without enabling this option. Would anybody hate if we just removed the CONFIG_X86_X2APIC prompt entirely?