Received: by 2002:a05:6359:322:b0:b3:69d0:12d8 with SMTP id ef34csp485712rwb; Wed, 10 Aug 2022 11:28:22 -0700 (PDT) X-Google-Smtp-Source: AA6agR6Pux4SSDbXcqCXv3UExFuzlOKHr0G1OqYRtg6UALSs+Z7kMpOb4MBwJI8q5D6vgk7LwwdR X-Received: by 2002:a17:903:247:b0:16c:5017:9ad4 with SMTP id j7-20020a170903024700b0016c50179ad4mr29851791plh.115.1660156101980; Wed, 10 Aug 2022 11:28:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660156101; cv=none; d=google.com; s=arc-20160816; b=0qZMU35++A3ZzRee5JwEi0fQpy5yPg1geq+Iz51LpIy2JZVaa6VXI2D4AwFMKFUEcD uDgnBuNPoUUFRp5ESQtbTd3VWnWGMTE/RCm15qn0UiHvqoUrf4JgVqF5n7+J43/SBnOC oVAqhWqXQn5YzPlzXL40B6ek8Z5mjLU2XKscDoRUoemA/k8ES8HCC6TBUSDZtgx6U9NT KCEMU3oMyXd21I+hWD7/hpp1Bb36H3S1aCsiTu+JbTFnwEVQ8LFQ246BX87t0xlwB6/A xSOSFc+CYB6NYDV2ShmfVTmVYr+7sql0xk4JPr5LgQM6UIWtMEZFsju0mp2ee4Gz7kC3 /Yjg== 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=9o1IpyZmnyORSF8h4EAMoiT/lrqWL8zS648oDXtkwcc=; b=y7TjHrS7PmqQ6VVytZl4vNuhkd7C+AIJ5NWSIZCK0SKWLbX3Rn+YegFuh/5GEWbCzf bH7BpY378gQiiD0EYvfjh8BedoXoTCYmIfvN4zwBlRsr6e5jz2uOWJtXdapIEattwSLj xw75j8Q9ieCzj9fLz2TJ9S97G5LUH1K2E0Pv+xem765PpeWxA+yStBF+hE44axy/dG+J QPu7dq0IdTIZm/YT6mleCdCsgaaFef7a2RfT+RAzxr6f8HCNE4IZbUlRYWNEbyCXfOa4 0WMn1+2oogMx00Ukxo/VbF6nCdApqlMce8IMQ9d5xdVabUyd/29FNFlSY8X8ikEaWlh6 NUjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=F4kjhcXR; 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 5-20020a630c45000000b0041dff983839si1279267pgm.453.2022.08.10.11.28.07; Wed, 10 Aug 2022 11:28:21 -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=F4kjhcXR; 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 S233360AbiHJSBd (ORCPT + 99 others); Wed, 10 Aug 2022 14:01:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233005AbiHJSBa (ORCPT ); Wed, 10 Aug 2022 14:01:30 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78A5111A2F for ; Wed, 10 Aug 2022 11:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660154489; x=1691690489; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=3rTmOyYZVT0I5124ROCzwftBtAV5MQs3DeNu/klIUxI=; b=F4kjhcXRK1SETFg3KgRfKkfeGVU5j2trtX1sR1K8Vp0kTn6XxycmgAto sOlw5+Fqw1rLcRuaWWIh76wYTvWctaB1kqzZeTUZ8GH0uElXjTi2qAUFq 44MsjR6gQsYhuYO1TC89jU6c/KsJt6tMqKVSctg1EqI4UuKlzCoXLVuIK i8ld3o3g1Lp8TwBXLwtB3qDpg+mHVBnXSzMIOCgXfjyz6FFbd+pKpMkul Ba/TuAvgT1M4rFrh9fCTshSQOFc3l/5cEr09rnLziC84NZX4sJv0DNKKk 7kn4+ucpIbkg5qqx3BYznE0J8X5wb5qbX8m5XNLrXd89Y4gdbEIJVtAdU w==; X-IronPort-AV: E=McAfee;i="6400,9594,10435"; a="288723059" X-IronPort-AV: E=Sophos;i="5.93,228,1654585200"; d="scan'208";a="288723059" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2022 11:01:28 -0700 X-IronPort-AV: E=Sophos;i="5.93,228,1654585200"; d="scan'208";a="781317211" 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 11:01:28 -0700 Message-ID: Date: Wed, 10 Aug 2022 11:01:29 -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 References: <20220809234000.783284-1-daniel.sneddon@linux.intel.com> From: Dave Hansen In-Reply-To: <20220809234000.783284-1-daniel.sneddon@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.7 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_HI,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/9/22 16:40, Daniel Sneddon wrote: > The APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC > (or x2APIC). X2APIC mode is mostly compatible with legacy APIC, but > it disables the memory-mapped APIC interface in favor of one that uses > MSRs. The APIC mode is controlled by the EXT bit in the APIC MSR. > > Introduce support for a new feature that will allow the BIOS to lock > the APIC in x2APIC mode. If the APIC is locked in x2APIC mode and the > kernel tries to disable the APIC or revert to legacy APIC mode a GP > fault will occur. > > Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handle the > new locked mode when the LEGACY_XAPIC_DISABLED bit is set. > > If the LEGACY_XAPIC_DISABLED is set, prevent the kernel > from trying to disable it. Let's also not obscure the fact that the MMIO/xAPIC interface is troublesome and there are real-world, practical reasons a piece of hardware might not want to implement it. First on the list is: https://aepicleak.com/ Second on the list is TDX. The TDX module spec currently just dictates that TDX guests must use x2APIC. If this (IA32_XAPIC_DISABLE_STATUS) mechanism was enumerated to TDX guests, they could use this instead of crashing in burning in whatever horrid way they are now if someone disables x2APIC on the command line. It would also be nice to know roughly when this feature is showing up. If it's going to show up as a part of a microcode update for my laptop next week or next month, this might warrant a backport. Intel would presumably *want* a backport to happen there, too. If it's going to be on one server CPU that's coming out in ten years, then we can hold off. It might also help to link to the documentation, even if it's below a "--" in the changelog since these URLs aren't very stable. > https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html or at least mention what the status of the documentation is. The code looks OK to me, but I'm far from impartial because this isn't my first look at it. In any case: Acked-by: Dave Hansen