Linux Confidential Computing Development
 help / color / mirror / Atom feed
From: Sohil Mehta <sohil.mehta@intel.com>
To: Rick Edgecombe <rick.p.edgecombe@intel.com>, <bp@alien8.de>,
	<dave.hansen@intel.com>, <hpa@zytor.com>, <kas@kernel.org>,
	<kvm@vger.kernel.org>, <linux-coco@lists.linux.dev>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<mingo@redhat.com>, <nik.borisov@suse.com>, <pbonzini@redhat.com>,
	<seanjc@google.com>, <tglx@kernel.org>, <vannapurve@google.com>,
	<x86@kernel.org>, <chao.gao@intel.com>, <yan.y.zhao@intel.com>,
	<kai.huang@intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Binbin Wu <binbin.wu@linux.intel.com>
Subject: Re: [PATCH v6 02/11] x86/virt/tdx: Allocate page bitmap for Dynamic PAMT
Date: Tue, 7 Jul 2026 17:49:03 -0700	[thread overview]
Message-ID: <efbff823-7b4e-4349-bdc4-72a244699d76@intel.com> (raw)
In-Reply-To: <20260526023515.288829-3-rick.p.edgecombe@intel.com>

On 5/25/2026 7:35 PM, Rick Edgecombe wrote:
> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> 
> The TDX Physical Address Metadata Table (PAMT) holds data about the
> physical memory used by TDX, and must be allocated by the kernel during
> TDX module initialization.
> 
> The exact size of the required PAMT memory is determined by the TDX module
> and may vary between TDX module versions. Currently it is approximately
> 0.4% of the system memory. This is a significant commitment, especially if
> it is not known upfront whether the machine will run any TDX guests.
> 
> Each memory region that the TDX module might use needs three separate PAMT
> allocations. One for each supported page size (1GB, 2MB, 4KB). The
> TDX module supports a new feature designed to reduce PAMT overhead called
> Dynamic PAMT. At a high level, Dynamic PAMT still has the 1GB and 2MB
> levels allocated on TDX module initialization, but the 4KB level is
> allocated dynamically during runtime.

The last statement is slightly confusing to me. Is it trying to say that
the "dynamic" part is only applicable to 4KB allocations?


> 
> However, in the details, Dynamic PAMT still needs some smaller per 4KB
> page scoped data (currently it is 1 bit per page). The TDX module exposes
> the number of bits as a separate piece of metadata than the 4KB static
> allocation for regular PAMT. Although the size is enumerated differently,
> it is handed to the TDX module in the same way the 4KB page size PAMT
> allocation is for regular, non-dynamic PAMT.
> 
> Begin to implement Dynamic PAMT in the kernel by reading the bits-per-page
> needed for Dynamic PAMT. Calculate the size needed for the bitmap,
> and use it instead of the 4KB size determined for normal PAMT, in the case
> of Dynamic PAMT.
> 
> Unlike the existing metadata reading code, this code is not generated by a
> script. 


It might be useful to say that this file was auto-generated in the past
but going forward it is going to be manually updated.

> So adjust the comment to be more generic. Also, start to adopt a
> more normal kernel code style without the tenary statements and if

s/a more/
s/tenary/ternary


> conditionals assignments that the auto generated code has.
> 
> Assisted-by: Sashiko:claude-opus-4-6
> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>

The review tags goes after the SOBs.

> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Co-developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> ---

> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index 503f9a3f46d61..82dc27aecf297 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -149,6 +149,11 @@ static __always_inline u64 sc_retry(sc_func_t func, u64 fn,
>  const char *tdx_dump_mce_info(struct mce *m);
>  const struct tdx_sys_info *tdx_get_sysinfo(void);
>  
> +static inline bool tdx_supports_dynamic_pamt(const struct tdx_sys_info *sysinfo)
> +{
> +	return false; /* To be enabled when kernel is ready */

I would avoid the tail comment even if it is temporary.

> +}
> +
>  int tdx_guest_keyid_alloc(void);
>  u32 tdx_get_nr_guest_keyids(void);
>  void tdx_guest_keyid_free(unsigned int keyid);



> @@ -33,6 +33,18 @@ static __init int get_tdx_sys_info_features(struct tdx_sys_info_features *sysinf
>  	return ret;
>  }
>  
> +static __init int get_tdx_sys_info_tdmr_dpamt(struct tdx_sys_info_tdmr *sysinfo_tdmr)
> +{
> +	int ret;
> +	u64 val;
> +
> +	ret = read_sys_metadata_field(0x9100000100000013, &val);

Should this be a #define now that the file is being manually updated? Or
is the plan to do it all together? A #define would make it easier to
read this patch.

> +	if (!ret)
> +		sysinfo_tdmr->pamt_page_bitmap_entry_bits = val;
> +
> +	return ret;
> +}
> +
>  static __init int get_tdx_sys_info_tdmr(struct tdx_sys_info_tdmr *sysinfo_tdmr)
>  {
>  	int ret = 0;
> @@ -116,5 +128,12 @@ static __init int get_tdx_sys_info(struct tdx_sys_info *sysinfo)
>  	ret = ret ?: get_tdx_sys_info_td_ctrl(&sysinfo->td_ctrl);
>  	ret = ret ?: get_tdx_sys_info_td_conf(&sysinfo->td_conf);
>  
> +	/*
> +	 * Don't treat a module that doesn't support Dynamic PAMT
> +	 * as a failure. Only read the metadata optionally.
> +	 */
> +	if (!ret && tdx_supports_dynamic_pamt(sysinfo))
> +		ret = get_tdx_sys_info_tdmr_dpamt(&sysinfo->tdmr);

There is a need for the comment because it combines two checks:

1) Did any of the previous stages fail?
2) Does the TDX module support Dynamic PAMT?

Should these be separated for readability and to follow the typical
kernel style?

	if (ret)
		return ret;

	if (tdx_supports_dynamic_pamt(sysinfo))
		ret = get_tdx_sys_info_tdmr_dpamt(&sysinfo->tdmr);

	return ret;

I think you can avoid the comment altogether in that case.

> +
>  	return ret;
>  }


  parent reply	other threads:[~2026-07-08  0:49 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26  2:35 [PATCH v6 00/11] Dynamic PAMT Rick Edgecombe
2026-05-26  2:35 ` [PATCH v6 01/11] x86/virt/tdx: Simplify tdmr_get_pamt_sz() Rick Edgecombe
2026-06-04 16:05   ` Kiryl Shutsemau
2026-07-01  0:08     ` Edgecombe, Rick P
2026-06-11 18:25   ` Vishal Annapurve
2026-07-03  5:48   ` Chao Gao
2026-07-06 20:18     ` Edgecombe, Rick P
2026-07-07  3:24       ` Yan Zhao
2026-07-07 19:08         ` Edgecombe, Rick P
2026-07-07 23:22   ` Sohil Mehta
2026-07-08  1:23     ` Edgecombe, Rick P
2026-05-26  2:35 ` [PATCH v6 02/11] x86/virt/tdx: Allocate page bitmap for Dynamic PAMT Rick Edgecombe
2026-06-04 16:14   ` Kiryl Shutsemau
2026-07-01  0:14     ` Edgecombe, Rick P
2026-06-11 18:47   ` Vishal Annapurve
2026-07-03  8:26   ` Chao Gao
2026-07-07  3:59   ` Yan Zhao
2026-07-07 21:25     ` Edgecombe, Rick P
2026-07-08  0:49   ` Sohil Mehta [this message]
2026-05-26  2:35 ` [PATCH v6 03/11] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers Rick Edgecombe
2026-06-08  2:11   ` Binbin Wu
2026-06-08  2:18     ` Yan Zhao
2026-07-01  0:15       ` Edgecombe, Rick P
2026-07-06 12:31   ` Chao Gao
2026-07-06 20:23     ` Edgecombe, Rick P
2026-05-26  2:35 ` [PATCH v6 04/11] x86/virt/tdx: Allocate ref counts for Dynamic PAMT memory Rick Edgecombe
2026-07-02  7:20   ` Binbin Wu
2026-07-06 20:26     ` Edgecombe, Rick P
2026-07-06 13:22   ` Chao Gao
2026-07-06 20:26     ` Edgecombe, Rick P
2026-07-07  4:53   ` Yan Zhao
2026-07-07 22:32     ` Edgecombe, Rick P
2026-05-26  2:35 ` [PATCH v6 05/11] x86/virt/tdx: Handle concurrent callers in tdx_pamt_get/put() Rick Edgecombe
2026-07-02  7:39   ` Binbin Wu
2026-07-06 20:27     ` Edgecombe, Rick P
2026-07-07  5:54   ` Chao Gao
2026-05-26  2:35 ` [PATCH v6 06/11] x86/virt/tdx: Optimize tdx_pamt_get/put() Rick Edgecombe
2026-05-26  8:57   ` Chao Gao
2026-05-26 16:42     ` Edgecombe, Rick P
2026-06-04 16:59       ` Kiryl Shutsemau
2026-06-05  5:40         ` Chao Gao
2026-06-05 11:42           ` Kiryl Shutsemau
2026-06-05 16:23             ` Dave Hansen
2026-06-08  9:14               ` Kiryl Shutsemau
2026-06-08  9:50               ` Yan Zhao
2026-07-01  1:45                 ` Edgecombe, Rick P
2026-07-01  5:37                   ` Yan Zhao
2026-07-01  1:05               ` Edgecombe, Rick P
2026-07-07  6:45   ` Chao Gao
2026-05-26  2:35 ` [PATCH v6 07/11] KVM: TDX: Allocate PAMT memory for TD and vCPU control structures Rick Edgecombe
2026-07-02  8:55   ` Binbin Wu
2026-07-06 23:47   ` Sean Christopherson
2026-07-06 23:54     ` Edgecombe, Rick P
2026-07-07  0:25       ` Sean Christopherson
2026-07-07  6:54   ` Chao Gao
2026-05-26  2:35 ` [PATCH v6 08/11] x86/tdx: Add APIs to support Dynamic PAMT ops from KVM's fault path Rick Edgecombe
2026-06-04 17:11   ` Kiryl Shutsemau
2026-07-02  9:32   ` Binbin Wu
2026-07-07  7:25   ` Chao Gao
2026-05-26  2:35 ` [PATCH v6 09/11] KVM: TDX: Get/put PAMT pages when (un)mapping private memory Rick Edgecombe
2026-07-03  3:15   ` Binbin Wu
2026-07-06 20:47     ` Edgecombe, Rick P
2026-07-06 21:02       ` Sean Christopherson
2026-07-06 21:52         ` Edgecombe, Rick P
2026-05-26  2:35 ` [PATCH v6 10/11] x86/virt/tdx: Enable Dynamic PAMT Rick Edgecombe
2026-06-04 17:14   ` Kiryl Shutsemau
2026-06-05  5:25     ` Chao Gao
2026-07-01  1:20       ` Edgecombe, Rick P
2026-07-06 20:48         ` Edgecombe, Rick P
2026-07-03  4:35   ` Binbin Wu
2026-05-26  2:35 ` [PATCH v6 11/11] Documentation/x86: Add documentation for TDX's " Rick Edgecombe
2026-07-03  4:54   ` Binbin Wu
2026-06-08  5:45 ` [PATCH v6 00/11] " Tony Lindgren
2026-07-06 21:01 ` Edgecombe, Rick P
2026-07-07 16:17   ` Sean Christopherson
2026-07-07 17:25     ` 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=efbff823-7b4e-4349-bdc4-72a244699d76@intel.com \
    --to=sohil.mehta@intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=chao.gao@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=kai.huang@intel.com \
    --cc=kas@kernel.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nik.borisov@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@kernel.org \
    --cc=vannapurve@google.com \
    --cc=x86@kernel.org \
    --cc=yan.y.zhao@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