Re: [PATCH v3 09/26] coco/tdx-host: Expose P-SEAMLDR information via sysfs

[Dave Hansen]

On 1/30/26 06:44, Chao Gao wrote:
>>> +What:		/sys/devices/faux/tdx_host/seamldr/num_remaining_updates
>>> +Contact:	linux-coco@xxxxxxxxxxxxxxx
>>> +Description:	(RO) Report the number of remaining updates that can be performed.
>>> +		The CPU keeps track of TCB versions for each TDX Module that
>>> +		has been loaded. Since this tracking database has finite
>>> +		capacity, there's a maximum number of Module updates that can
>>> +		be performed.
>>
>> Is it really the CPU? Or some SEAM software construct?
> 
> It is the CPU. The CPU provides the database and gives instructions to
> P-SEAMLDR for adding records or cleaning up the entire database.

Either way, it's an implementation detail that doesn't need to be
litigated in the OS ABI docs.

	TDX maintains a log about each TDX module which has been loaded.
	This log has a finite size which limits the number of TDX module
	updates which can be performed.

	Report the number of updates remaining.

>>> +#ifdef CONFIG_INTEL_TDX_MODULE_UPDATE

...
> /facepalm. Sorry for missing these important considerations.
> 
> I overlooked a critical constraint: only one CPU can call P-SEAMLDR at a time;
> any second CPU gets VMFailInvalid. Patch 19 adds a lock for SEAMLDR.INSTALL
> serialization, but we actually need to serialize all P-SEAMLDR calls or handle
> VMFailInvalid with retries.
> 
> I will make the following changes to see how they look:
> 
> 1. Move the lock from patch 19 to seamldr_call() to serialize all P-SEAMLDR calls

Ack, yes, this is obviously required.

> 2. Cache seamldr_info and only update it after successful updates
> 3. Make seamldr_get_info() return cached data instead of calling P-SEAMLDR every time

To be honest, I'm not sure we need a cache. Why don't we just make the
permissions 400 and keep the info structure on the stack?