mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"yilun.xu@linux.intel.com" <yilun.xu@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>
Cc: "Gao, Chao" <chao.gao@intel.com>,
	"Xu, Yilun" <yilun.xu@intel.com>,
	"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
	"kas@kernel.org" <kas@kernel.org>,
	"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
	"Li, Xiaoyao" <xiaoyao.li@intel.com>,
	"Maloor, Kishen" <kishen.maloor@intel.com>,
	"Hunter, Adrian" <adrian.hunter@intel.com>,
	"tony.lindgren@linux.intel.com" <tony.lindgren@linux.intel.com>,
	"Mehta, Sohil" <sohil.mehta@intel.com>,
	"Fang, Peter" <peter.fang@intel.com>,
	"nik.borisov@suse.com" <nik.borisov@suse.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"artem.bityutskiy@linux.intel.com"
	<artem.bityutskiy@linux.intel.com>
Subject: Re: [PATCH v2 2/5] x86/virt/tdx: Configure add-on features on TDX module init
Date: Tue, 15 Sep 2026 20:54:01 +0000	[thread overview]
Message-ID: <2f6ac9afef52386fc491145222ea46e54c24a73f.camel@intel.com> (raw)
In-Reply-To: <20260915102658.713079-3-yilun.xu@linux.intel.com>

On Tue, 2026-09-15 at 18:26 +0800, Xu Yilun wrote:
> @@ -1012,12 +1021,22 @@ struct tdmr_info_pa_array {
>  static __init int tdx_sys_config(struct tdmr_info_pa_array *tdmr_pa_array,
>  				 unsigned int nr_tdmr_pa, u64 global_keyid)
>  {
> +	u64 addon_features0 = get_tdx_addon_features0();
>  	struct tdx_module_args args = {
>  		.rcx = __pa(tdmr_pa_array),
>  		.rdx = nr_tdmr_pa,
>  		.r8 = global_keyid,
>  	};

It seems inconsistent that global_keyid is passed in even though it is basically
global state, while addon_features0 is retrieved from the global state. Passing
the result of get_tdx_addon_features0() in from the caller doesn't make a ton of
sense. And we already reference tdx_global_keyid globally from another seamcall
wrapper. So I'd think dropping the arg when you create the wrapper would be best
in the end.

The smallest change to stay consistent would be go add an addon_features0 arg to
tdx_sys_config(), but it's hard to justify as good code. I'd maybe go with the
global_keyid change and it probably is a separate patch, but we are brushing up
against mixing cleanup and feature enabling... thoughts?


>  
> +	/*
> +	 * Use SEAMCALL version 1 that supports add-on features if any are
> +	 * requested. Otherwise use version 0 for backward compatibility.
> +	 */
> +	if (addon_features0) {
> +		args.r9 = addon_features0;
> +		args.version = 1;
> +	}
> +
>  	return seamcall_prerr(TDH_SYS_CONFIG, &args);
>  }


  reply	other threads:[~2026-09-15 20:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 10:26 [PATCH v2 0/5] Enable TDX module extensions Xu Yilun
2026-09-15 10:26 ` [PATCH v2 1/5] x86/virt/tdx: Move TDH.SYS.CONFIG operations into a wrapper Xu Yilun
2026-09-15 20:45   ` Edgecombe, Rick P
2026-09-15 10:26 ` [PATCH v2 2/5] x86/virt/tdx: Configure add-on features on TDX module init Xu Yilun
2026-09-15 20:54   ` Edgecombe, Rick P [this message]
2026-09-16  3:23   ` Chao Gao
2026-09-15 10:26 ` [PATCH v2 3/5] x86/virt/tdx: Detect if the extensions initialization is required Xu Yilun
2026-09-15 21:14   ` Edgecombe, Rick P
2026-09-15 10:26 ` [PATCH v2 4/5] x86/virt/tdx: Add extra memory to TDX module for the extensions Xu Yilun
2026-09-15 21:19   ` Edgecombe, Rick P
2026-09-16  7:40   ` Chao Gao
2026-09-15 10:26 ` [PATCH v2 5/5] x86/virt/tdx: Make TDX module initialize " Xu Yilun
2026-09-15 22:09 ` [PATCH v2 0/5] Enable TDX module extensions Edgecombe, Rick P

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f6ac9afef52386fc491145222ea46e54c24a73f.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chao.gao@intel.com \
    --cc=kas@kernel.org \
    --cc=kishen.maloor@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nik.borisov@suse.com \
    --cc=peter.fang@intel.com \
    --cc=sohil.mehta@intel.com \
    --cc=tony.lindgren@linux.intel.com \
    --cc=x86@kernel.org \
    --cc=xiaoyao.li@intel.com \
    --cc=yilun.xu@intel.com \
    --cc=yilun.xu@linux.intel.com \
    --cc=zhenzhong.duan@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®