Received-SPF: pass (google.com: domain of linux-kernel+bounces-137304-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <44af8014-f73c-4ef0-9692-07e8df18fe24@intel.com>
Date: Wed, 10 Apr 2024 00:13:36 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy
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>
Content-Language: en-US
From: Xiaoyao Li <xiaoyao.li@intel.com>
In-Reply-To: <4ae4769a6f343a2f4d3648e4348810df069f24b7.camel@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.

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