Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp5316523pxb; Mon, 28 Mar 2022 10:49:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHOG9y7nM7KHGDzS6rxWAJKdHjXfAubFub46+saRN6VAAsy/M8hZNU51qwEcS6OP61QrH1 X-Received: by 2002:a17:90b:38d2:b0:1c6:fa94:96bb with SMTP id nn18-20020a17090b38d200b001c6fa9496bbmr316319pjb.206.1648489782873; Mon, 28 Mar 2022 10:49:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648489782; cv=none; d=google.com; s=arc-20160816; b=F9TZCy44H3vl48GKasHXoYhj2hxYWYhYjLxnhvjUmvpc8hEqyBNgQ7dp10348FYjN3 O7n7A0qQl+XA9q3VzBfbtomuL9mYUhUodf2Ee8q8ELs4NndA8ldUEYkUEKpqT14Ubu6u Vnh58zbuZbKVlLXJj7ojgRXB1xia2zFNvb3S/oxtn6QgFO2Z++FXOZ16keJp6hsW8R3w /0duKLAWDcg1b+p5UIvDlHEsi8QHOMyR6I/A76TbHMZCSJ4mnEBYP05/hhym4UfgLEpG tUNZOlwFhgwJ/q7NZnNPxKAoa/6PeCQat3dHGjPdIrEcPUjJg/LNja0JGpe2TfYgluon o9HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=dH4wyo0kNqUWkN1UwFTWz0myNBrqXgMLcescAVijUvA=; b=BnZjQxvz53i3Ud4z8DdJOwCYQWC6THTZMbyhYh04RAR6y2O7LEsXKNq4hxk57C3H4V 1xue/9POnZbKRVdGvCqCYhlw7yIbIeKVbXvCzZf7N3nKOwqyAm1AlJfPYVkXANf0q/v/ EzOMLNKdOygk0C6riu3k5Z1I8U57pTbIk+sEPHSFYlh498sSv6uY4g7os2cgAuXGXsQ7 spOaQ6u3avKQgOJH1csTOBZbArOgFVZR9CbwTop7z5Bok+aVXhbYCWO1BI3e4dOmf1eA HQKEuhzEZfRhruf5c1R242M/Ymi7lGKDRNemjxdLt12vveYEd6M09rj+JecP3pIG3y0T wL9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=U3vuF2kB; 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 d75-20020a621d4e000000b004fa848bc2d0si14088080pfd.132.2022.03.28.10.49.27; Mon, 28 Mar 2022 10:49:42 -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=U3vuF2kB; 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 S237873AbiC1D4s (ORCPT + 99 others); Sun, 27 Mar 2022 23:56:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229754AbiC1D4q (ORCPT ); Sun, 27 Mar 2022 23:56:46 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09EF5220D8; Sun, 27 Mar 2022 20:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1648439706; x=1679975706; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=1IrgS1Xz4xDu9eaps5L0yXyUmT/Eaqj8UxN5lOp2JiA=; b=U3vuF2kBsyAx6Hih/UaZgUNuhyrEC9meVxDcrlvok1lFX2OgKjjDKhzA /UaD6np6Gd+oIuh2mOjV7ABjfGXUNeEpW/ETIG0G5GErqG2v3r82Zec8j +iZLemustXErmG/vxVdCGTMqzFuuzARIxm8vSaiDfrPmAeiuuEKMZ0S7h 0JB5F8PK3Mw1+YwyYWAPSzbBU4wUhRLiRfu9PEPdW8Tf4LKR+Zlqc1We3 smrhGY54PTs0fqoT0VA2MGGkSsQIVULILP9iwEsYeUuPNpzn3VPoDYhDh M3xBennDfLhL6bmuKHDr327exzECY1BuXNdrmQ0iiMNOYOdiGlXTO1KI8 Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10299"; a="239502536" X-IronPort-AV: E=Sophos;i="5.90,216,1643702400"; d="scan'208";a="239502536" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Mar 2022 20:55:05 -0700 X-IronPort-AV: E=Sophos;i="5.90,216,1643702400"; d="scan'208";a="638819456" Received: from stung2-mobl.gar.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.94.73]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Mar 2022 20:55:03 -0700 Message-ID: <51982ec477e43c686c5c64731715fee528750d85.camel@intel.com> Subject: Re: [PATCH v2 01/21] x86/virt/tdx: Detect SEAM From: Kai Huang To: "Tian, Kevin" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" Cc: "Hansen, Dave" , "Christopherson,, Sean" , "pbonzini@redhat.com" , "kirill.shutemov@linux.intel.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "peterz@infradead.org" , "Luck, Tony" , "ak@linux.intel.com" , "Williams, Dan J" , "Yamahata, Isaku" Date: Mon, 28 Mar 2022 16:55:01 +1300 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, 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 Wed, 2022-03-23 at 16:21 +1300, Tian, Kevin wrote: > > From: Kai Huang > > Sent: Sunday, March 13, 2022 6:50 PM > > > > @@ -715,6 +716,8 @@ static void init_intel(struct cpuinfo_x86 *c) > >       if (cpu_has(c, X86_FEATURE_TME)) > >               detect_tme(c); > > > > + tdx_detect_cpu(c); > > + > > TDX is not reported as a x86 feature. and the majority of detection > and initialization have been conducted on demand in this series > (as explained in patch04). Why is SEAM (and latter keyid) so different > to be detected at early boot phase? > > Thanks > Kevin Hi Kevin, Sorry for late reply. I was out last week. SEAMRR and TDX KeyIDs are configured by BIOS and they are static during machine's runtime. On the other hand, TDX module can be updated and reinitialized at runtime (not supported in this series but will be supported in the future). Theoretically, even P-SEAMLDR can be updated at runtime (although I think unlikely to be supported in Linux). Therefore I think detecting SEAMRR and TDX KeyIDs at boot fits better. It is also more flexible from some other perspectives I think: 1) There was a request to add X86_FEATURE_SEAM bit and expose it to /proc/cpuinfo. I didn't add it because I didn't think the use case was solid. But in case someone has some use case in the future we can add it, and detecting SEAMRR during boot fits this more. 2) There was a request to expose TDX KeyID info via sysfs so userspace can know how many TDs can be created. It's not done in this series but it will be done at some time in the future. Detecting KeyIDs at boot allows this info being able to be exposed via sysfs at early stage, providing more flexibility to userspace. At last, currently in this series the patch to handle kexec checks whether SEAMRR and TDX KeyIDs are enabled and then flush cache (of course this is open to discussion). Detecting them at boot fits better I think. -- Thanks, -Kai