Received: by 2002:a05:6359:322:b0:b3:69d0:12d8 with SMTP id ef34csp163888rwb; Wed, 10 Aug 2022 17:03:12 -0700 (PDT) X-Google-Smtp-Source: AA6agR7PiAI/7A4pWjtDl4ZbstkNAXFigipPB9DZGBsXaERg0p1su5VWrvKsd14Vnpo4N+fxEF61 X-Received: by 2002:a63:9142:0:b0:41b:f217:8b83 with SMTP id l63-20020a639142000000b0041bf2178b83mr25128558pge.478.1660176192308; Wed, 10 Aug 2022 17:03:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660176192; cv=none; d=google.com; s=arc-20160816; b=BKwHlK0gvmGBwIi80tnOqNMnyCnPbl3Ys2uXzjVsmXlOgJ/0lMOZb/jfzU6XDl+73M l6gTZT1GoYx9SdrFYkRypt0WAXl9pzTLhV/ztYZbSO9tmkucS+C1Z8nzOn+QXZgIYvE/ Hs/vIVPRJ6GX/X1n5EqTLvcj6QxAU4aonNdrISoGwhNhET96UIlz089eW7OsdGZEO8ik 4XFkk1Ioycn9dEmjwXW7KGCxbYTo6aYPfJWULdLOChVRGllfvjzpq2nPVzqUI5xIySTv UR+TPc++42Y/fQS4RZSjecx00JYdCLqMn5xeqpIAkjvURtGX87qYOUlaCJn4FJBxeLTT K+Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=h92HOnmufMm+5rMqbmXShMFPYNbZJfdTO/GKfvo0nwU=; b=f/tdp9QhgOYUP/fUDeCrxDmaanoFt7y0iwi9cRvG4ME4jUtdTABiAppWp+816KD4fp it++02QU3IrsVDLkmL1ivOXS08vqu29LCXi8VkVuQ4/YHCt947V1YLdcm8fu21LSae+x pfvBWUzldzFcNtL0Zhf7GZJ0gVuXraXW5hqyFaGz1QKNJc8BArNDMaXSN8fJieZTEYF6 m8HO5uCTTtNAuSa4MFk7QpVdgGNGGoTsLXx25HlWgzXsiVkTMEY7HMC4hclizSHaful+ 1Ml8u3243BWoeySWibytLpLMOlLRPepBSkMJkuWSG8cKaEHuBpD2gpm1RwX3Sff40bpf 0qCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=MLpBRO8c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b16-20020a170902d51000b0016d74d2c965si13609622plg.377.2022.08.10.17.02.58; Wed, 10 Aug 2022 17:03:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=MLpBRO8c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233543AbiHJXoW (ORCPT + 99 others); Wed, 10 Aug 2022 19:44:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229868AbiHJXoU (ORCPT ); Wed, 10 Aug 2022 19:44:20 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 100CB7B1D4 for ; Wed, 10 Aug 2022 16:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660175060; x=1691711060; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=oteDUqBYG8zZP5eboPGY4mFmY0qdZlXGZreN0Xphx28=; b=MLpBRO8cG1n9rNPO9WZ4KkOwwwa4Z9AHto+TS4mOLQTovZPveplaVno+ zQ/9iL4iBZPwift/gT6oxoihCiTxwPHKV4GRqiBE+1Ji6Z90kMJlVjwbb LSCGkmMlMUsbqkcDNHHZ7cJe47YE0YodkjRP/REf9SjmiDuhr5Who9W5T edGLRARvl85OnEaTFq1nBbMYc01EH04EbpSpPfWVbv5PAohvOaXqO95yA S2yc0ZticZ+ZI9YWpF5wxhUnqefnhl0ZvKY3FmhUwNsB/GpRo4w2FuVfG /q/jQMj+oWutCKSWNltQcMv3tIq8o3En4e64qfdes3mBZrhnyYG0/zbcu g==; X-IronPort-AV: E=McAfee;i="6400,9594,10435"; a="292010908" X-IronPort-AV: E=Sophos;i="5.93,228,1654585200"; d="scan'208";a="292010908" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2022 16:44:19 -0700 X-IronPort-AV: E=Sophos;i="5.93,228,1654585200"; d="scan'208";a="781407402" 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 16:44:18 -0700 Message-ID: <9888a920-37b8-9a1f-b887-6630492955c6@intel.com> Date: Wed, 10 Aug 2022 16:44:20 -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" , "Huang, Kai" 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> <87r11nu52l.ffs@tglx> <83a0d220-1872-caba-4e7e-b6a366655cf2@linux.intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/10/22 16:38, Daniel Sneddon wrote: >> >> config INTEL_TDX_GUEST >> bool "Intel TDX (Trust Domain Extensions) - Guest Support" >> depends on X86_64 && CPU_SUP_INTEL >> depends on X86_X2APIC > So I got some more input. SPR and newer will lock the APIC. Could you get a _little_ more clarity on this, please? Exactly how and when will it be locked? What does the BIOS writer's guide say? Will there be an explicit x2APIC lock option? Or, will it be implicitly locked when SGX or TDX is enabled? > Older products will get a ucode update, but that ucode update won't > include the APIClock. So, on non-SPR parts do we still want to make > SGX depend on X2APIC? Yes. It's a small price to pay.