public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Kai Huang <kai.huang@intel.com>
Cc: <linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	<dave.hansen@intel.com>, <dan.j.williams@intel.com>,
	<kirill.shutemov@linux.intel.com>, <rick.p.edgecombe@intel.com>,
	<peterz@infradead.org>, <tglx@linutronix.de>, <bp@alien8.de>,
	<mingo@redhat.com>, <hpa@zytor.com>, <seanjc@google.com>,
	<pbonzini@redhat.com>, <kvm@vger.kernel.org>,
	<isaku.yamahata@intel.com>, <binbin.wu@linux.intel.com>
Subject: Re: [PATCH 8/9] x86/virt/tdx: Exclude memory region hole within CMR as TDMR's reserved area
Date: Mon, 17 Jun 2024 18:54:38 +0800	[thread overview]
Message-ID: <ZnAV7krcGEqyHQt2@chao-email> (raw)
In-Reply-To: <cfbed1139887416b6fe0d130883dbe210e97d598.1718538552.git.kai.huang@intel.com>

>+/* Return whether a given region [start, end) is a sub-region of any CMR */
>+static bool is_cmr_subregion(struct tdx_sysinfo_cmr_info *cmr_info, u64 start,
>+			    u64 end)
>+{
>+	int i;
>+
>+	for (i = 0; i < cmr_info->num_cmrs; i++) {
>+		u64 cmr_base = cmr_info->cmr_base[i];
>+		u64 cmr_size = cmr_info->cmr_size[i];
>+
>+		if (start >= cmr_base && end <= (cmr_base + cmr_size))
>+			return true;
>+	}
>+
>+	return false;
>+}
>+
> /*
>  * Go through @tmb_list to find holes between memory areas.  If any of

The logic here is:
1. go through @tmb_list to find holes
2. skip a hole if it is in CMRs

I am wondering if the kernel can traverse CMRs directly to find holes. This
way, the new is_cmr_subregion() can be removed. And @tmb_list can be dropped
from a few functions e.g., tdmr_populate_rsvd_holes/areas/areas_all(). So, this
will simplify those functions a bit.

>  * those holes fall within @tdmr, set up a TDMR reserved area to cover
>@@ -835,7 +932,8 @@ static int tdmr_add_rsvd_area(struct tdmr_info *tdmr, int *p_idx, u64 addr,
> static int tdmr_populate_rsvd_holes(struct list_head *tmb_list,
> 				    struct tdmr_info *tdmr,
> 				    int *rsvd_idx,
>-				    u16 max_reserved_per_tdmr)
>+				    u16 max_reserved_per_tdmr,
>+				    struct tdx_sysinfo_cmr_info *cmr_info)

Maybe this function can accept a pointer to tdx_sysinfo and remove
@max_reserved_per_tdmr and @cmr_info because they are both TDX metadata and
have only one possible combination for a given TDX module. Anyway, I don't have
a strong opinion on this.

> {
> 	struct tdx_memblock *tmb;
> 	u64 prev_end;
>@@ -864,10 +962,16 @@ static int tdmr_populate_rsvd_holes(struct list_head *tmb_list,
> 		 * Skip over memory areas that
> 		 * have already been dealt with.
> 		 */
>-		if (start <= prev_end) {
>-			prev_end = end;
>-			continue;
>-		}
>+		if (start <= prev_end)
>+			goto next_tmb;
>+
>+		/*
>+		 * Found the hole [prev_end, start) before this region.
>+		 * Skip the hole if it is within any CMR to reduce the
>+		 * consumption of reserved areas.
>+		 */
>+		if (is_cmr_subregion(cmr_info, prev_end, start))
>+			goto next_tmb;
> 
> 		/* Add the hole before this region */
> 		ret = tdmr_add_rsvd_area(tdmr, rsvd_idx, prev_end,
>@@ -876,11 +980,16 @@ static int tdmr_populate_rsvd_holes(struct list_head *tmb_list,
> 		if (ret)
> 			return ret;
> 
>+next_tmb:
> 		prev_end = end;
> 	}
> 
>-	/* Add the hole after the last region if it exists. */
>-	if (prev_end < tdmr_end(tdmr)) {
>+	/*
>+	 * Add the hole after the last region if it exists, but skip
>+	 * if it is within any CMR.
>+	 */
>+	if (prev_end < tdmr_end(tdmr) &&
>+			!is_cmr_subregion(cmr_info, prev_end, tdmr_end(tdmr))) {
> 		ret = tdmr_add_rsvd_area(tdmr, rsvd_idx, prev_end,
> 				tdmr_end(tdmr) - prev_end,
> 				max_reserved_per_tdmr);

  reply	other threads:[~2024-06-17 10:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-16 12:01 [PATCH 0/9] TDX host: metadata reading tweaks, bug fix and info dump Kai Huang
2024-06-16 12:01 ` [PATCH 1/9] x86/virt/tdx: Rename _offset to _member for TD_SYSINFO_MAP() macro Kai Huang
2024-06-16 12:01 ` [PATCH 2/9] x86/virt/tdx: Unbind global metadata read with 'struct tdx_tdmr_sysinfo' Kai Huang
2024-06-18 11:23   ` Nikolay Borisov
2024-06-18 23:29     ` Huang, Kai
2024-06-16 12:01 ` [PATCH 3/9] x86/virt/tdx: Support global metadata read for all element sizes Kai Huang
2024-06-18 11:42   ` Nikolay Borisov
2024-06-18 23:28     ` Huang, Kai
2024-06-19  8:05   ` Nikolay Borisov
2024-06-19  9:51     ` Huang, Kai
2024-06-16 12:01 ` [PATCH 4/9] x86/virt/tdx: Abstract reading multiple global metadata fields as a helper Kai Huang
2024-06-18 11:45   ` Nikolay Borisov
2024-06-18 23:42     ` Huang, Kai
2024-06-16 12:01 ` [PATCH 5/9] x86/virt/tdx: Move field mapping table of getting TDMR info to function local Kai Huang
2024-06-18 11:47   ` Nikolay Borisov
2024-06-18 23:44     ` Huang, Kai
2024-06-16 12:01 ` [PATCH 6/9] x86/virt/tdx: Start to track all global metadata in one structure Kai Huang
2024-06-18 13:17   ` Nikolay Borisov
2024-06-18 23:54     ` Huang, Kai
2024-06-16 12:01 ` [PATCH 7/9] x86/virt/tdx: Print TDX module basic information Kai Huang
2024-06-18 13:52   ` Nikolay Borisov
2024-06-19  0:22     ` Huang, Kai
2024-06-16 12:01 ` [PATCH 8/9] x86/virt/tdx: Exclude memory region hole within CMR as TDMR's reserved area Kai Huang
2024-06-17 10:54   ` Chao Gao [this message]
2024-06-18  0:12     ` Huang, Kai
2024-06-18 15:10   ` Nikolay Borisov
2024-06-19  1:23     ` Huang, Kai
2024-06-19  4:58       ` Huang, Kai
2024-07-05  3:00       ` Binbin Wu
2024-07-05  9:36         ` Huang, Kai
2024-06-16 12:01 ` [PATCH 9/9] x86/virt/tdx: Don't initialize module that doesn't support NO_RBP_MOD feature Kai Huang
2024-06-18 15:12   ` Nikolay Borisov

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=ZnAV7krcGEqyHQt2@chao-email \
    --to=chao.gao@intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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