Re: [PATCH 02/15] x86/virt/tdx: Add extra memory to TDX Module for Extensions

[Adrian Hunter <adrian.hunter@intel.com>]

On 10/06/2026 08:13, Xu Yilun wrote:
> On Tue, Jun 09, 2026 at 04:38:31PM +0300, Adrian Hunter wrote:
>> On 22/05/2026 06:41, Xu Yilun wrote:
>>> +static int tdx_ext_mem_add(struct page *root, unsigned int nr_pages)
>>> +{
>>> +	struct tdx_module_args args = {
>>> +		.rcx = to_hpa_list_info(root, nr_pages),
>>> +	};
>>> +	u64 r;
>>> +
>>> +	tdx_clflush_hpa_list(root, nr_pages);
>>> +
>>> +	do {
>>> +		/*
>>> +		 * TDH_EXT_MEM_ADD is designed to use output parameter RCX to
>>> +		 * override/update input parameter RCX, so the caller doesn't
>>> +		 * have to do manual parameter update on retry call.
>>> +		 */
>>> +		r = seamcall_ret(TDH_EXT_MEM_ADD, &args);
>>> +	} while (r == TDX_INTERRUPTED_RESUMABLE);
>>
>> Kishon already mentioned checking only the status
> 
> Could you elaborate on why we should mask? I assume the mask is only
> needed when the lower bits ([31:0]) are defined to contain extra
> information. TDX_INTERRUPTED_RESUMABLE is not the case so we could make
> the code change simpler.
> 
> And if some non-zero bits appears there, it is a Module bug that we
> should not skip.

Agreed

> 
>>
>>> +
>>> +	if (r != TDX_SUCCESS)
>>
>> Similarly could this also be TDX_EXT_MEMORY_POOL_FULL?
> 
> I don't think we should pass the case. The Module provides the number of
> required pages via metadata, host follows and feeds pages but the Module
> said "Sorry, I'm already full". This is inconsistent behavior that we
> should call out.

TDX_EXT_MEMORY_POOL_FULL is not an error code. It is a success code,
so the question is whether it will ever show up on, say, the very last
TDH_EXT_MEM_ADD.

> 
>>
>>> +		return -EFAULT;
>>> +
>>> +	return 0;
>>> +}
>>