linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Kai Huang <kai.huang@intel.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: linux-mm@kvack.org, seanjc@google.com, pbonzini@redhat.com,
	dan.j.williams@intel.com, rafael.j.wysocki@intel.com,
	kirill.shutemov@linux.intel.com, ying.huang@intel.com,
	reinette.chatre@intel.com, len.brown@intel.com,
	tony.luck@intel.com, peterz@infradead.org, ak@linux.intel.com,
	isaku.yamahata@intel.com, chao.gao@intel.com,
	sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com,
	sagis@google.com, imammedo@redhat.com
Subject: Re: [PATCH v7 12/20] x86/virt/tdx: Create TDMRs to cover all TDX memory regions
Date: Wed, 23 Nov 2022 14:41:55 -0800	[thread overview]
Message-ID: <d84ad1d2-83f9-dab5-5639-8d71f382e3ff@intel.com> (raw)
In-Reply-To: <4db59b4a87f0309c29e61a79892b9fa6645754a8.1668988357.git.kai.huang@intel.com>

On 11/20/22 16:26, Kai Huang wrote:
> The kernel configures TDX-usable memory regions by passing an array of
> "TD Memory Regions" (TDMRs) to the TDX module.  Each TDMR contains the
> information of the base/size of a memory region, the base/size of the
> associated Physical Address Metadata Table (PAMT) and a list of reserved
> areas in the region.
> 
> Create a number of TDMRs to cover all TDX memory regions.  To keep it
> simple, always try to create one TDMR for each memory region.  As the
> first step only set up the base/size for each TDMR.
> 
> Each TDMR must be 1G aligned and the size must be in 1G granularity.
> This implies that one TDMR could cover multiple memory regions.  If a
> memory region spans the 1GB boundary and the former part is already
> covered by the previous TDMR, just create a new TDMR for the remaining
> part.
> 
> TDX only supports a limited number of TDMRs.  Disable TDX if all TDMRs
> are consumed but there is more memory region to cover.

Good changelog.  This patch is doing *one* thing.

>  arch/x86/virt/vmx/tdx/tdx.c | 104 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 103 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index 26048c6b0170..57b448de59a0 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -445,6 +445,24 @@ static int build_tdx_memory(void)
>  	return ret;
>  }
>  
> +/* TDMR must be 1gb aligned */
> +#define TDMR_ALIGNMENT		BIT_ULL(30)
> +#define TDMR_PFN_ALIGNMENT	(TDMR_ALIGNMENT >> PAGE_SHIFT)
> +
> +/* Align up and down the address to TDMR boundary */
> +#define TDMR_ALIGN_DOWN(_addr)	ALIGN_DOWN((_addr), TDMR_ALIGNMENT)
> +#define TDMR_ALIGN_UP(_addr)	ALIGN((_addr), TDMR_ALIGNMENT)
> +
> +static inline u64 tdmr_start(struct tdmr_info *tdmr)
> +{
> +	return tdmr->base;
> +}

I'm always skeptical that it's a good idea to take this in code:

	tdmr->base

and make it this:

	tdmr_start(tdmr)

because the helper is *LESS* compact than the open-coded form!  I hope
I'm proven wrong.

> +static inline u64 tdmr_end(struct tdmr_info *tdmr)
> +{
> +	return tdmr->base + tdmr->size;
> +}
> +
>  /* Calculate the actual TDMR_INFO size */
>  static inline int cal_tdmr_size(void)
>  {
> @@ -492,14 +510,98 @@ static struct tdmr_info *alloc_tdmr_array(int *array_sz)
>  	return alloc_pages_exact(*array_sz, GFP_KERNEL | __GFP_ZERO);
>  }
>  
> +static struct tdmr_info *tdmr_array_entry(struct tdmr_info *tdmr_array,
> +					  int idx)
> +{
> +	return (struct tdmr_info *)((unsigned long)tdmr_array +
> +			cal_tdmr_size() * idx);
> +}

FWIW, I think it's probably a bad idea to have 'struct tdmr_info *'
types floating around since:

	tmdr_info_array[0]

works, but:

	tmdr_info_array[1]

will blow up in your face.  It would almost make sense to have

struct tdmr_info_list {
	struct tdmr_info *first_tdmr;
}

and then pass around pointers to the 'struct tdmr_info_list'.  Maybe
that's overkill, but it is kinda silly to call something an array if []
doesn't work on it.

> +/*
> + * Create TDMRs to cover all TDX memory regions.  The actual number
> + * of TDMRs is set to @tdmr_num.
> + */
> +static int create_tdmrs(struct tdmr_info *tdmr_array, int *tdmr_num)
> +{
> +	struct tdx_memblock *tmb;
> +	int tdmr_idx = 0;
> +
> +	/*
> +	 * Loop over TDX memory regions and create TDMRs to cover them.
> +	 * To keep it simple, always try to use one TDMR to cover
> +	 * one memory region.
> +	 */

This seems like it might tend to under-utilize TDMRs.  I'm sure this is
done for simplicity, but is it OK?  Why is it OK?  How are you sure this
won't bite us later?

> +	list_for_each_entry(tmb, &tdx_memlist, list) {
> +		struct tdmr_info *tdmr;
> +		u64 start, end;
> +
> +		tdmr = tdmr_array_entry(tdmr_array, tdmr_idx);
> +		start = TDMR_ALIGN_DOWN(tmb->start_pfn << PAGE_SHIFT);
> +		end = TDMR_ALIGN_UP(tmb->end_pfn << PAGE_SHIFT);

Nit: a little vertical alignment can make this much more readable:

		start = TDMR_ALIGN_DOWN(tmb->start_pfn << PAGE_SHIFT);
		end   = TDMR_ALIGN_UP  (tmb->end_pfn   << PAGE_SHIFT);

> +
> +		/*
> +		 * If the current TDMR's size hasn't been initialized,
> +		 * it is a new TDMR to cover the new memory region.
> +		 * Otherwise, the current TDMR has already covered the
> +		 * previous memory region.  In the latter case, check
> +		 * whether the current memory region has been fully or
> +		 * partially covered by the current TDMR, since TDMR is
> +		 * 1G aligned.
> +		 */

Again, we have a comment over a if() block that describes what the
individual steps in the block do.  *Plus* each individual step is
*ALREADY* commented.  What purpose does this comment serve?

> +		if (tdmr->size) {
> +			/*
> +			 * Loop to the next memory region if the current
> +			 * block has already been fully covered by the
> +			 * current TDMR.
> +			 */
> +			if (end <= tdmr_end(tdmr))
> +				continue;
> +
> +			/*
> +			 * If part of the current memory region has
> +			 * already been covered by the current TDMR,
> +			 * skip the already covered part.
> +			 */
> +			if (start < tdmr_end(tdmr))
> +				start = tdmr_end(tdmr);
> +
> +			/*
> +			 * Create a new TDMR to cover the current memory
> +			 * region, or the remaining part of it.
> +			 */
> +			tdmr_idx++;
> +			if (tdmr_idx >= tdx_sysinfo.max_tdmrs)
> +				return -E2BIG;
> +
> +			tdmr = tdmr_array_entry(tdmr_array, tdmr_idx);
> +		}
> +
> +		tdmr->base = start;
> +		tdmr->size = end - start;
> +	}
> +
> +	/* @tdmr_idx is always the index of last valid TDMR. */
> +	*tdmr_num = tdmr_idx + 1;
> +
> +	return 0;
> +}

Seems like a positive return value could be the number of populated
TDMRs.  That would get rid of the int* argument.

>  /*
>   * Construct an array of TDMRs to cover all TDX memory ranges.
>   * The actual number of TDMRs is kept to @tdmr_num.
>   */

OK, so something else allocated the 'tdmr_array' and it's being passed
in here to fill it out.  "construct" and "create" are both near synonyms
for "allocate", which isn't even being done here.

We want something here that will make it clear that this function is
taking an already populated list of TDMRs and filling it out.
"fill_tmdrs()" seems like it might be a better choice.

This is also a place where better words can help.  If the function is
called "construct", then there's *ZERO* value in using the same word in
the comment.  Using a word that is a close synonym but that can contrast
it with something different would be really nice, say:

This is also a place where the calling convention can be used to add
clarity.  If you implicitly use a global variable, you have to explain
that.  But, if you pass *in* a variable, it's a lot more clear.

Take this, for instance:

/*
 * Take the memory referenced in @tdx_memlist and populate the
 * preallocated @tmdr_array, following all the special alignment
 * and size rules for TDMR.
 */
static int fill_out_tdmrs(struct list_head *tdx_memlist,
			  struct tdmr_info *tdmr_array)
{
...

That's 100% crystal clear about what's going on.  You know what the
inputs are and the outputs.  You also know why this is even necessary.
It's implied a bit, but it's because TDMRs have special rules about
size/alignment and tdx_memlists do not.

>  static int construct_tdmrs(struct tdmr_info *tdmr_array, int *tdmr_num)
>  {
> +	int ret;
> +
> +	ret = create_tdmrs(tdmr_array, tdmr_num);
> +	if (ret)
> +		goto err;
> +
>  	/* Return -EINVAL until constructing TDMRs is done */
> -	return -EINVAL;
> +	ret = -EINVAL;
> +err:
> +	return ret;
>  }
>  
>  /*


  reply	other threads:[~2022-11-23 22:42 UTC|newest]

Thread overview: 163+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21  0:26 [PATCH v7 00/20] TDX host kernel support Kai Huang
2022-11-21  0:26 ` [PATCH v7 01/20] x86/tdx: Define TDX supported page sizes as macros Kai Huang
2022-11-21  2:52   ` Sathyanarayanan Kuppuswamy
2022-11-21  9:15     ` Huang, Kai
2022-11-21 17:23       ` Sathyanarayanan Kuppuswamy
2022-11-21 18:12     ` Dave Hansen
2022-11-21 23:48   ` Dave Hansen
2022-11-22  0:01     ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 02/20] x86/virt/tdx: Detect TDX during kernel boot Kai Huang
2022-11-21  3:07   ` Sathyanarayanan Kuppuswamy
2022-11-21  9:37     ` Huang, Kai
2022-11-21 23:57       ` Sathyanarayanan Kuppuswamy
2022-11-22  0:10   ` Dave Hansen
2022-11-22 11:28     ` Huang, Kai
2022-11-22 16:50       ` Dave Hansen
2022-11-22 23:21         ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 03/20] x86/virt/tdx: Disable TDX if X2APIC is not enabled Kai Huang
2022-11-21  3:51   ` Sathyanarayanan Kuppuswamy
2022-11-21  9:44     ` Huang, Kai
2022-11-21 22:00       ` Sathyanarayanan Kuppuswamy
2022-11-21 23:40         ` Huang, Kai
2022-11-21 23:46   ` Dave Hansen
2022-11-22  0:30     ` Huang, Kai
2022-11-22  0:44       ` Dave Hansen
2022-11-22  0:58         ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 04/20] x86/virt/tdx: Add skeleton to initialize TDX on demand Kai Huang
2022-11-22  9:02   ` Peter Zijlstra
2022-11-22 10:31     ` Thomas Gleixner
2022-11-22 15:35       ` Dave Hansen
2022-11-22 20:03         ` Thomas Gleixner
2022-11-22 20:11           ` Sean Christopherson
2022-11-23  0:30           ` Huang, Kai
2022-11-23  1:12             ` Huang, Kai
2022-11-23 11:05             ` Thomas Gleixner
2022-11-23 12:22               ` Huang, Kai
2022-11-22 18:05   ` Dave Hansen
2022-11-23 10:18     ` Huang, Kai
2022-11-23 16:58       ` Dave Hansen
2022-11-23 21:58         ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 05/20] x86/virt/tdx: Implement functions to make SEAMCALL Kai Huang
2022-11-22  9:06   ` Peter Zijlstra
2022-11-23  8:53     ` Huang, Kai
2022-11-22 18:20   ` Dave Hansen
2022-11-23 10:43     ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 06/20] x86/virt/tdx: Shut down TDX module in case of error Kai Huang
2022-11-22  9:10   ` Peter Zijlstra
2022-11-22  9:13   ` Peter Zijlstra
2022-11-22 15:14     ` Dave Hansen
2022-11-22 19:13       ` Peter Zijlstra
2022-11-22 19:24         ` Dave Hansen
2022-11-22 19:33           ` Peter Zijlstra
2022-11-23  1:14             ` Huang, Kai
2022-11-29 21:40             ` Dave Hansen
2022-11-30 11:09               ` Thomas Gleixner
2022-11-23  0:58           ` Huang, Kai
2022-11-23  1:04             ` Dave Hansen
2022-11-23  1:22               ` Huang, Kai
2022-11-23 16:20                 ` Sean Christopherson
2022-11-23 16:41                   ` Dave Hansen
2022-11-23 17:37                     ` Sean Christopherson
2022-11-23 18:18                       ` Dave Hansen
2022-11-23 19:03                         ` Sean Christopherson
2022-11-22  9:20   ` Peter Zijlstra
2022-11-22 15:06     ` Thomas Gleixner
2022-11-22 19:06       ` Peter Zijlstra
2022-11-22 19:31         ` Sean Christopherson
2022-11-23  9:39           ` Huang, Kai
2022-11-22 15:20     ` Dave Hansen
2022-11-22 16:52       ` Thomas Gleixner
2022-11-22 18:57   ` Dave Hansen
2022-11-22 19:14     ` Peter Zijlstra
2022-11-23  1:24       ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 07/20] x86/virt/tdx: Do TDX module global initialization Kai Huang
2022-11-22 19:14   ` Dave Hansen
2022-11-23 11:45     ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 08/20] x86/virt/tdx: Do logical-cpu scope TDX module initialization Kai Huang
2022-11-21  0:26 ` [PATCH v7 09/20] x86/virt/tdx: Get information about TDX module and TDX-capable memory Kai Huang
2022-11-22 23:39   ` Dave Hansen
2022-11-23 11:40     ` Huang, Kai
2022-11-23 16:44       ` Dave Hansen
2022-11-23 22:53         ` Huang, Kai
2022-12-02 11:19           ` Huang, Kai
2022-12-02 17:25             ` Dave Hansen
2022-12-02 21:57               ` Huang, Kai
2022-12-02 11:11     ` Huang, Kai
2022-12-02 17:06       ` Dave Hansen
2022-12-02 21:56         ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 10/20] x86/virt/tdx: Use all system memory when initializing TDX module as TDX memory Kai Huang
2022-11-21  5:37   ` Huang, Ying
2022-11-21  9:09     ` Huang, Kai
2022-11-22  1:54       ` Huang, Ying
2022-11-22  9:16         ` Huang, Kai
2022-11-24  0:47           ` Huang, Ying
2022-11-22 10:10   ` Peter Zijlstra
2022-11-22 11:40     ` Huang, Kai
2022-11-23  0:21   ` Dave Hansen
2022-11-23  9:29     ` Peter Zijlstra
2022-11-24  1:04     ` Huang, Kai
2022-11-24  1:22       ` Dave Hansen
2022-11-24  2:27         ` Huang, Kai
2022-11-24  1:50   ` Dan Williams
2022-11-24  9:06     ` Huang, Kai
2022-11-25  9:28       ` David Hildenbrand
2022-11-28  8:38         ` Huang, Kai
2022-11-28  8:43           ` David Hildenbrand
2022-11-28  9:21             ` Huang, Kai
2022-11-28  9:26               ` David Hildenbrand
2022-11-28  9:50                 ` Huang, Kai
2022-11-24  9:26     ` Peter Zijlstra
2022-11-24 10:02       ` Huang, Kai
2022-11-30 22:26         ` Dave Hansen
2022-11-21  0:26 ` [PATCH v7 11/20] x86/virt/tdx: Add placeholder to construct TDMRs to cover all TDX memory regions Kai Huang
2022-11-23 22:17   ` Dave Hansen
2022-11-24  9:51     ` Huang, Kai
2022-11-24 12:02     ` Huang, Kai
2022-11-28 15:59       ` Dave Hansen
2022-11-28 22:13         ` Huang, Kai
2022-11-28 22:19           ` Dave Hansen
2022-11-28 22:50             ` Huang, Kai
2022-12-07 11:47               ` Huang, Kai
2022-12-08 12:56                 ` Huang, Kai
2022-12-08 14:58                   ` Dave Hansen
2022-12-08 23:29                     ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 12/20] x86/virt/tdx: Create " Kai Huang
2022-11-23 22:41   ` Dave Hansen [this message]
2022-11-24 11:29     ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 13/20] x86/virt/tdx: Allocate and set up PAMTs for TDMRs Kai Huang
2022-11-23 22:57   ` Dave Hansen
2022-11-24 11:46     ` Huang, Kai
2022-11-28 16:39       ` Dave Hansen
2022-11-28 22:48         ` Huang, Kai
2022-11-28 22:56           ` Dave Hansen
2022-11-28 23:14             ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 14/20] x86/virt/tdx: Set up reserved areas for all TDMRs Kai Huang
2022-11-23 23:39   ` Dave Hansen
2022-11-28  9:14     ` Huang, Kai
2022-11-28 13:18       ` Dave Hansen
2022-11-28 22:24         ` Huang, Kai
2022-11-28 22:58           ` Dave Hansen
2022-11-28 23:10             ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 15/20] x86/virt/tdx: Reserve TDX module global KeyID Kai Huang
2022-11-23 23:40   ` Dave Hansen
2022-11-24 22:39     ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 16/20] x86/virt/tdx: Configure TDX module with TDMRs and " Kai Huang
2022-11-23 23:56   ` Dave Hansen
2022-11-25  0:59     ` Huang, Kai
2022-11-25  1:18       ` Dave Hansen
2022-11-25  1:44         ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 17/20] x86/virt/tdx: Configure global KeyID on all packages Kai Huang
2022-11-24  0:28   ` Dave Hansen
2022-11-24 22:28     ` Huang, Kai
2022-11-25  0:08       ` Huang, Kai
2022-11-30  3:35   ` Binbin Wu
2022-11-30  8:34     ` Huang, Kai
2022-11-30 14:04       ` kirill.shutemov
2022-11-30 15:13       ` Dave Hansen
2022-11-30 20:17         ` Huang, Kai
2022-11-30 17:37   ` Dave Hansen
2022-11-21  0:26 ` [PATCH v7 18/20] x86/virt/tdx: Initialize all TDMRs Kai Huang
2022-11-24  0:42   ` Dave Hansen
2022-11-25  2:27     ` Huang, Kai
2022-11-21  0:26 ` [PATCH v7 19/20] x86/virt/tdx: Flush cache in kexec() when TDX is enabled Kai Huang
2022-11-21  0:26 ` [PATCH v7 20/20] Documentation/x86: Add documentation for TDX host support Kai Huang

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=d84ad1d2-83f9-dab5-5639-8d71f382e3ff@intel.com \
    --to=dave.hansen@intel.com \
    --cc=ak@linux.intel.com \
    --cc=bagasdotme@gmail.com \
    --cc=chao.gao@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=imammedo@redhat.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=reinette.chatre@intel.com \
    --cc=sagis@google.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=tony.luck@intel.com \
    --cc=ying.huang@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;
as well as URLs for NNTP newsgroup(s).