mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@intel.com>
To: "Hansen, Dave" <dave.hansen@intel.com>,
	"seanjc@google.com" <seanjc@google.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"nik.borisov@suse.com" <nik.borisov@suse.com>,
	"Hunter, Adrian" <adrian.hunter@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"Yamahata, Isaku" <isaku.yamahata@intel.com>
Subject: Re: [PATCH v5 2/8] x86/virt/tdx: Rework TD_SYSINFO_MAP to support build-time verification
Date: Tue, 15 Oct 2024 11:34:41 +0000	[thread overview]
Message-ID: <9a06e2cf469cbca2777ac2c4ef70579e6bb934d5.camel@intel.com> (raw)
In-Reply-To: <670d6d4cab43d_3ee229434@dwillia2-xfh.jf.intel.com.notmuch>

On Mon, 2024-10-14 at 12:13 -0700, Dan Williams wrote:
> Dave Hansen wrote:
> > On 10/14/24 04:31, Kai Huang wrote:
> > > +#define READ_SYS_INFO(_field_id, _member)				\
> > > +	ret = ret ?: read_sys_metadata_field16(MD_FIELD_ID_##_field_id,	\
> > > +					&sysinfo_tdmr->_member)
> > >  
> > > -	return 0;
> > > +	READ_SYS_INFO(MAX_TDMRS,	     max_tdmrs);
> > > +	READ_SYS_INFO(MAX_RESERVED_PER_TDMR, max_reserved_per_tdmr);
> > > +	READ_SYS_INFO(PAMT_4K_ENTRY_SIZE,    pamt_entry_size[TDX_PS_4K]);
> > > +	READ_SYS_INFO(PAMT_2M_ENTRY_SIZE,    pamt_entry_size[TDX_PS_2M]);
> > > +	READ_SYS_INFO(PAMT_1G_ENTRY_SIZE,    pamt_entry_size[TDX_PS_1G]);
> > 
> > I know what Dan asked for here, but I dislike how this ended up.
> > 
> > The existing stuff *has* type safety, despite the void*.  It at least
> > checks the size, which is the biggest problem.
> > 
> > Also, this isn't really an unrolled loop.  It still effectively has
> > gotos, just like the for loop did.  It just buries the goto in the "ret
> > = ret ?: " construct.  It hides the control flow logic.
> > 
> > Logically, this whole function is
> > 
> > 	ret = read_something1();
> > 	if (ret)
> > 		goto out;
> > 
> > 	ret = read_something2();
> > 	if (ret)
> > 		goto out;
> > 
> > 	...
> > 
> > I'd *much* rather have that goto be:
> > 
> > 	for () {
> > 		ret = read_something();
> > 		if (ret)
> > 			break; // aka. goto out
> > 	}
> > 
> > Than have something *look* like straight control flow when it isn't.

Yeah understood.  Thanks for letting me know.

The 'for() loop' approach would need the original 'struct field_mapping' to hold
the mapping between field ID and the offset/size info, though.

> 
> Yeah, the hiding of the control flow was the weakest part of the
> suggestion. My main gripe was runtime validation of details that could
> be validated at compile time.

I am looking into how to do build-time verification while still using the
original 'struct field_mapping' approach.  If we can do this, I hope this can
address your concern about doing runtime check instead of build-time?

Adrian provided one suggestion [*] that we can use __builtin_choose_expr() to
achieve this:

"
BUILD_BUG_ON() requires a function, but it is still
be possible to add a build time check in TD_SYSINFO_MAP
e.g.

#define TD_SYSINFO_CHECK_SIZE(_field_id, _size)			\
	__builtin_choose_expr(MD_FIELD_ELE_SIZE(_field_id) == _size, _size,
(void)0)

#define _TD_SYSINFO_MAP(_field_id, _offset, _size)		\
	{ .field_id = _field_id,				\
	  .offset   = _offset,					\
	  .size	    = TD_SYSINFO_CHECK_SIZE(_field_id, _size) }

#define TD_SYSINFO_MAP(_field_id, _struct, _member)		\
	_TD_SYSINFO_MAP(MD_FIELD_ID_##_field_id,		\
			offsetof(_struct, _member),		\
			sizeof(typeof(((_struct *)0)->_member)))
"

I tried this, and it worked for most cases where the field ID is a simple
integer constant, but I got build error for the CMRs:

	for (u16 i = 0; i < cmr_info->num_cmrs; i++) {
		const struct field_mapping fields[] = {
			TD_SYSINFO_CMRINFO_MAP(CMR_BASE0 + i, cmr_base[i]),
			TD_SYSINFO_CMRINFO_MAP(CMR_SIZE0 + i, cmr_size[i]),
		};
		...
	}

.. where field ID for CMR[i] is calculated by CMR0.

The MD_FIELD_ELE_SIZE(_field_id) works for 'CMR_BASE0 + i' for BUILD_BUG_ON(),
but somehow the compiler fails to determine the 'MD_FIELD_ELE_SIZE(_field_id) ==
_size' as a constant_express and caused build failure.  I am still looking into
this.

[*]
https://lore.kernel.org/kvm/cover.1721186590.git.kai.huang@intel.com/T/#m379ce041f025dc20e7b58fa6dbdc484c2ce53af4

> There is no real need for control flow at all, i.e. early exit is not
> needed as these are not resources that need to be unwound. It simply
> needs to count whether all of the reads happened, so something like this
> is sufficient:
> 
>     success += READ_SYS_INFO(MAX_TDMRS,             max_tdmrs);
>     success += READ_SYS_INFO(MAX_RESERVED_PER_TDMR, max_reserved_per_tdmr);
>     success += READ_SYS_INFO(PAMT_4K_ENTRY_SIZE,    pamt_entry_size[TDX_PS_4K]);
>     success += READ_SYS_INFO(PAMT_2M_ENTRY_SIZE,    pamt_entry_size[TDX_PS_2M]);
>     success += READ_SYS_INFO(PAMT_1G_ENTRY_SIZE,    pamt_entry_size[TDX_PS_1G]);
>     
>     if (success != 5)
>     	return false;
> 

If we go with this approach, it seems we can even get rid of the @success.

	int ret = 0;

#define READ_SYS_INFO(_field_id, _member)	\
	read_sys_metadata_field(MD_FIELD_ID_##_field_id, \
	                                     &sysinfo_tdmr->_member)

	ret |= READ_SYS_INFO(MAX_TDMRS, max_tdmrs);
	...
#undef READ_SYS_INFO

	return ret;

The tdh_sys_rd() always return -EIO when TDH.SYS.RD fails, so the above either
return 0 when all reads were successful or -EIO when there's any failed.

I can also go with route if Dave is fine?

  reply	other threads:[~2024-10-15 11:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-14 11:31 [PATCH v5 0/8] TDX host: metadata reading tweaks, bug fix and info dump Kai Huang
2024-10-14 11:31 ` [PATCH v5 1/8] x86/virt/tdx: Rename 'struct tdx_tdmr_sysinfo' to reflect the spec better Kai Huang
2024-10-14 11:31 ` [PATCH v5 2/8] x86/virt/tdx: Rework TD_SYSINFO_MAP to support build-time verification Kai Huang
2024-10-14 15:56   ` Dave Hansen
2024-10-14 19:13     ` Dan Williams
2024-10-15 11:34       ` Huang, Kai [this message]
2024-10-14 11:31 ` [PATCH v5 3/8] x86/virt/tdx: Prepare to support reading other global metadata fields Kai Huang
2024-10-14 11:31 ` [PATCH v5 4/8] x86/virt/tdx: Refine a comment to reflect the latest TDX spec Kai Huang
2024-10-14 11:31 ` [PATCH v5 5/8] x86/virt/tdx: Start to track all global metadata in one structure Kai Huang
2024-10-14 11:31 ` [PATCH v5 6/8] x86/virt/tdx: Print TDX module version Kai Huang
2024-10-14 11:31 ` [PATCH v5 7/8] x86/virt/tdx: Require the module to assert it has the NO_RBP_MOD mitigation Kai Huang
2024-10-14 11:31 ` [PATCH v5 8/8] x86/virt/tdx: Reduce TDMR's reserved areas by using CMRs to find memory holes Kai Huang
2024-10-15 15:30 ` [PATCH v5 0/8] TDX host: metadata reading tweaks, bug fix and info dump Dave Hansen
2024-10-15 16:29   ` Paolo Bonzini
2024-10-15 19:04     ` Dan Williams
2024-10-15 21:11       ` Huang, Kai
2024-10-28 12:07     ` Huang, Kai

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=9a06e2cf469cbca2777ac2c4ef70579e6bb934d5.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=adrian.hunter@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=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nik.borisov@suse.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

all inboxes | Powered by JetHome®