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

On Mon, Aug 24, 2026 at 08:15:41AM -0700, Dave Hansen wrote:
> 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?

Because I thought func_low_level() mirrors the TDX ABI. This SEAMCALL ABI
is defined to get 4 inputs from the host, while helper() is the Linux's
policy (enable all add-ons) to generate the 4th input. Embed the Linux
policy in TDX ABI implementation feels a little off to me.

But I don't have strong preference. I can drop the addon_features0
argument.