Re: [PATCH 2/6] x86/virt/tdx: Configure add-on features on TDX module init and update

On 8/23/26 23:37, Xu Yilun wrote:
> On Fri, Aug 21, 2026 at 07:38:42AM -0700, Dave Hansen wrote:
>> On 8/20/26 20:29, Xu Yilun wrote:
>>>  static __init int tdx_sys_config(struct tdmr_info_pa_array *tdmr_pa_array,
>>> -				 u64 nr_tdmr_pa, u64 global_keyid)
>>> +				 u64 nr_tdmr_pa, u64 global_keyid,
>>> +				 u64 addon_features0)
>>
>> addon_features0 is just a copy of the global, static, not changing
>> get_tdx_addon_features0() return code, right?
>>
>> Why pass it around as a function argument?
> 
> I thought that we need some place to explicitly see the TDX ABI
> definition - what are the inputs the host should provide to the module.
> 
> The addon_features0 is the *option* the host should provide to the
> module according to the ABI. The global, static value for addon_features0
> is Linux's policy. So if we need to explicit the policy by the code,
> this helper and its arguments are good places to show the boundary.
> 
> But yes it does add boilerplate to the code, I can drop it.

I'm not arguing that the helper should go away.

What I'm seeing is this pattern:

int helper()
{
	return something;
}

int func_low_level(int arg)
{
	// use arg
}

int func()
{
	int foo = helper();

	// use foo

	func_low_level(foo);	
}

When it could use this pattern and just call helper() twice instead of
obtaining its return value and passing it around:

int helper()
{
	return something;
}

int func_low_level()
{
	int bar = helper();
	// use bar
}

int func()
{
	int foo = helper();

	// use foo

	func_low_level();	
}

So that's what I was asking. Why pass the result of helper() around when
you can just call helper() twice?