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?
next prev parent 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®