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

From: Adrian Hunter

Date: Wed Jun 10 2026 - 01:44:34 EST


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;
>>> +}
>>