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 8C279CD37B0 for ; Mon, 18 Sep 2023 15:57:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229811AbjIRP5M (ORCPT ); Mon, 18 Sep 2023 11:57:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229770AbjIRP5H (ORCPT ); Mon, 18 Sep 2023 11:57:07 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 297761729; Mon, 18 Sep 2023 08:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695052537; x=1726588537; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=kJ0CYEQlLTz2M55BKeG/DtPrqJTf7eCb6Wpd+3qKrgE=; b=JFcATaBdF64Sa7Zv48SKRKN5QhcCsdg/uiwUC3BO3gKrJCMbvqYkdQPH HjeUl7yDxKihtWQ0lkav+2Yx3c/TKCPdjPii1sDFrL8wnAYOXwIQXHgpb iOwbfjzg3LtueYinHKrCsieAZOXcNN5z0980fPlrglCuAftWRwMEkI9t0 FJ5mMEKuotOeRgcvddfeZ/lISbmBZv84+rCpEEECUBT3HMO4lX/Nobgbs cXzMWOe7I6WGUhawonrKbMWmgdN0rLLNPqIeY/17Os+SZIMjtDkEi3oA7 LZ3EiLk99l1PLATJshTwU/zreA+6l8VRiL/O/t4c4rnHJR8woP56KlXJ4 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10837"; a="446158379" X-IronPort-AV: E=Sophos;i="6.02,156,1688454000"; d="scan'208";a="446158379" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2023 08:44:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10837"; a="836076981" X-IronPort-AV: E=Sophos;i="6.02,156,1688454000"; d="scan'208";a="836076981" Received: from ecochran-mobl1.amr.corp.intel.com (HELO [10.212.244.237]) ([10.212.244.237]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2023 08:44:52 -0700 Message-ID: Date: Mon, 18 Sep 2023 08:44:51 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v13 17/22] x86/kexec: Flush cache of TDX private memory Content-Language: en-US To: "Huang, Kai" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Edgecombe, Rick P" Cc: "Raj, Ashok" , "Luck, Tony" , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "kirill.shutemov@linux.intel.com" , "Chatre, Reinette" , "Christopherson,, Sean" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "Yamahata, Isaku" , "nik.borisov@suse.com" , "mingo@redhat.com" , "hpa@zytor.com" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "bp@alien8.de" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" , "x86@kernel.org" References: <1fa1eb80238dc19b4c732706b40604169316eb34.1692962263.git.kai.huang@intel.com> <52e9ae7e-2e08-5341-99f7-b68eb62974df@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 9/18/23 05:08, Huang, Kai wrote: > On Fri, 2023-09-15 at 10:50 -0700, Dave Hansen wrote: >> On 9/15/23 10:43, Edgecombe, Rick P wrote: >>> On Sat, 2023-08-26 at 00:14 +1200, Kai Huang wrote: >>>> There are two problems in terms of using kexec() to boot to a new >>>> kernel when the old kernel has enabled TDX: 1) Part of the memory >>>> pages are still TDX private pages; 2) There might be dirty >>>> cachelines associated with TDX private pages. >>> Does TDX support hibernate? >> No. >> >> There's a whole bunch of volatile state that's generated inside the CPU >> and never leaves the CPU, like the ephemeral key that protects TDX >> module memory. >> >> SGX, for instance, never even supported suspend, IIRC. Enclaves just >> die and have to be rebuilt. > > Right. AFAICT TDX cannot survive from S3 either. All TDX keys get lost when > system enters S3. However I don't think TDX can be rebuilt after resume like > SGX. Let me confirm with TDX guys on this. By "rebuilt" I mean all private data is totally destroyed and rebuilt from scratch. The SGX architecture provides zero help other than delivering a fault and saying: "whoops all your data is gone". > I think we can register syscore_ops->suspend for TDX, and refuse to suspend when > TDX is enabled. This covers hibernate case too. > > In terms of how to check "TDX is enabled", ideally it's better to check whether > TDX module is actually initialized, but the worst case is we can use > platform_tdx_enabled(). (I need to think more on this) *Ideally* the firmware would have a choke point where it could just tell the OS that it can't suspend rather than the OS having to figure it out.