Received-SPF: pass (google.com: domain of linux-kernel+bounces-137308-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <99144e08-7852-4aef-addf-2c031b6cc62a@intel.com>
Date: Wed, 10 Apr 2024 00:18:52 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy
From: Xiaoyao Li <xiaoyao.li@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
 "seanjc@google.com" <seanjc@google.com>
Cc: "davidskidmore@google.com" <davidskidmore@google.com>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "srutherford@google.com" <srutherford@google.com>,
 "pankaj.gupta@amd.com" <pankaj.gupta@amd.com>,
 "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
 "Yamahata, Isaku" <isaku.yamahata@intel.com>,
 "Wang, Wei W" <wei.w.wang@intel.com>
References: <20240405165844.1018872-1-seanjc@google.com>
 <73b40363-1063-4cb3-b744-9c90bae900b5@intel.com>
 <ZhQZYzkDPMxXe2RN@google.com>
 <a17c6f2a3b3fc6953eb64a0c181b947e28bb1de9.camel@intel.com>
 <ZhQ8UCf40UeGyfE_@google.com>
 <5faaeaa7bc66dbc4ea86a64ef8e8f9b22fd22ef4.camel@intel.com>
 <ZhRxWxRLbnrqwQYw@google.com>
 <957b26d18ba7db611ed6582366066667267d10b8.camel@intel.com>
 <ZhSb28hHoyJ55-ga@google.com>
 <8b40f8b1d1fa915116ef1c95a13db0e55d3d91f2.camel@intel.com>
 <ZhVdh4afvTPq5ssx@google.com>
 <4ae4769a6f343a2f4d3648e4348810df069f24b7.camel@intel.com>
 <44af8014-f73c-4ef0-9692-07e8df18fe24@intel.com>
Content-Language: en-US
In-Reply-To: <44af8014-f73c-4ef0-9692-07e8df18fe24@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 4/10/2024 12:13 AM, Xiaoyao Li wrote:
> On 4/9/2024 11:49 PM, Edgecombe, Rick P wrote:
>>> I don't want JSON.  I want a data payload that is easily consumable 
>>> in C code,
>>> which contains (a) the bits that are fixed and (b) their values.  If 
>>> a value
>>> can
>>> change at runtime, it's not fixed.
>> Right. The fixed values have to come in a reasonable format from the 
>> TDX module
>> at runtime, or require an opt-in for any CPUID bits to change in 
>> future TDX
>> modules.
> 
> I have a thought for current situation that TDX module doesn't report 
> fixed CPUID bits via SEAMCALL interface but defines them in docs. VMM 
> (KVM or userspace) can maintain a hardcoded array of fixed CPUID bits 
> and their values according to TDX docs.  And VMM needs to update the 
> fixed array by striping out the bits that are reported in 
> TDSYSINFO.CPUID_CONFIG[], which are configurable.
> 
> If the newer TDX module changes some fixed bits to configurable bits, 
> They will show up in TDSYSINFO.CPUID_CONFIG[]. So VMM can update fixed 
> array correctly.
> 
> In fact, this is how TDX QEMU series current implements.
> 
> However, it requires TDX module to follow the rule that if any bit 
> becomes not fixed, it needs to be reported in TDSYSINFO.CPUID_CONFIG[] 
> as configurable.

If TDX module flips the bit between fixed0 and fixed1. It doesn't work 
neither. :(

> It's just for the case there is no interface from TDX module to report 
> the fixed CPUID bits in the end.
>