From: Adrian Hunter <adrian.hunter@intel.com>
To: "Huang, Kai" <kai.huang@intel.com>,
"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>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Gao, Chao" <chao.gao@intel.com>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v2 02/10] x86/virt/tdx: Unbind global metadata read with 'struct tdx_tdmr_sysinfo'
Date: Tue, 27 Aug 2024 07:54:54 +0300 [thread overview]
Message-ID: <7ae1fcac-cbea-478c-b8c9-d2c2a5dd6f11@intel.com> (raw)
In-Reply-To: <49dabff079d0b55bd169353d9ef159495ff2893e.camel@intel.com>
On 27/08/24 01:40, Huang, Kai wrote:
> On Mon, 2024-08-26 at 18:38 +0300, Adrian Hunter wrote:
>> On 7/08/24 15:09, Huang, Kai wrote:
>>> On Mon, 2024-08-05 at 18:13 -0700, Dan Williams wrote:
>>>> Huang, Kai wrote:
>>>> [..]
>>>>>> The unrolled loop is the same amount of work as maintaining @fields.
>>>>>
>>>>> Hi Dan,
>>>>>
>>>>> Thanks for the feedback.
>>>>>
>>>>> AFAICT Dave didn't like this way:
>>>>>
>>>>> https://lore.kernel.org/lkml/cover.1699527082.git.kai.huang@intel.com/T/#me6f615d7845215c278753b57a0bce1162960209d
>>>>
>>>> I agree with Dave that the original was unreadable. However, I also
>>>> think he glossed over the loss of type-safety and the silliness of
>>>> defining an array to precisely map fields only to turn around and do a
>>>> runtime check that the statically defined array was filled out
>>>> correctly. So I think lets solve the readability problem *and* make the
>>>> array definition identical in appearance to unrolled type-safe
>>>> execution, something like (UNTESTED!):
>>>>
>>>>
>>> [...]
>>>
>>>> +/*
>>>> + * Assumes locally defined @ret and @ts to convey the error code and the
>>>> + * 'struct tdx_tdmr_sysinfo' instance to fill out
>>>> + */
>>>> +#define TD_SYSINFO_MAP(_field_id, _offset) \
>>>> + ({ \
>>>> + if (ret == 0) \
>>>> + ret = read_sys_metadata_field16( \
>>>> + MD_FIELD_ID_##_field_id, &ts->_offset); \
>>>> + })
>>>> +
>>>
>>> We need to support u16/u32/u64 metadata field sizes, but not just u16.
>>>
>>> E.g.:
>>>
>>> struct tdx_sysinfo_module_info {
>>> u32 sys_attributes;
>>> u64 tdx_features0;
>>> };
>>>
>>> has both u32 and u64 in one structure.
>>>
>>> To achieve type-safety for all field sizes, I think we need one helper
>>> for each field size. E.g.,
>>>
>>> #define READ_SYSMD_FIELD_FUNC(_size) \
>>> static inline int \
>>> read_sys_metadata_field##_size(u64 field_id, u##_size *data) \
>>> { \
>>> u64 tmp; \
>>> int ret; \
>>> \
>>> ret = read_sys_metadata_field(field_id, &tmp); \
>>> if (ret) \
>>> return ret; \
>>> \
>>> *data = tmp; \
>>> return 0; \
>>> }
>>>
>>> /* For now only u16/u32/u64 are needed */
>>> READ_SYSMD_FIELD_FUNC(16)
>>> READ_SYSMD_FIELD_FUNC(32)
>>> READ_SYSMD_FIELD_FUNC(64)
>>>
>>> Is this what you were thinking?
>>>
>>> (Btw, I recall that I tried this before for internal review, but AFAICT
>>> Dave didn't like this.)
>>>
>>> For the build time check as you replied to the next patch, I agree it's
>>> better than the runtime warning check as done in the current code.
>>>
>>> If we still use the type-less 'void *stbuf' function to read metadata
>>> fields for all sizes, then I think we can do below:
>>>
>>> /*
>>> * Read one global metadata field and store the data to a location of a
>>> * given buffer specified by the offset and size (in bytes).
>>> */
>>> static int stbuf_read_sysmd_field(u64 field_id, void *stbuf, int offset,
>>> int size)
>>> {
>>> void *member = stbuf + offset;
>>> u64 tmp;
>>> int ret;
>>>
>>> ret = read_sys_metadata_field(field_id, &tmp);
>>> if (ret)
>>> return ret;
>>>
>>> memcpy(member, &tmp, size);
>>>
>>> return 0;
>>> }
>>>
>>> /* Wrapper to read one metadata field to u8/u16/u32/u64 */
>>> #define stbuf_read_sysmd_single(_field_id, _pdata) \
>>> stbuf_read_sysmd_field(_field_id, _pdata, 0, \
>>> sizeof(typeof(*(_pdata))))
>>>
>>> #define CHECK_MD_FIELD_SIZE(_field_id, _st, _member) \
>>> BUILD_BUG_ON(MD_FIELD_ELE_SIZE(MD_FIELD_ID_##_field_id) != \
>>> sizeof(_st->_member))
>>>
>>> #define TD_SYSINFO_MAP_TEST(_field_id, _st, _member) \
>>> ({ \
>>> if (ret) { \
>>> CHECK_MD_FIELD_SIZE(_field_id, _st, _member); \
>>> ret = stbuf_read_sysmd_single( \
>>> MD_FIELD_ID_##_field_id, \
>>> &_st->_member); \
>>> } \
>>> })
>>>
>>> static int get_tdx_module_info(struct tdx_sysinfo_module_info *modinfo)
>>> {
>>> int ret = 0;
>>>
>>> #define TD_SYSINFO_MAP_MOD_INFO(_field_id, _member) \
>>> TD_SYSINFO_MAP_TEST(_field_id, modinfo, _member)
>>>
>>> TD_SYSINFO_MAP_MOD_INFO(SYS_ATTRIBUTES, sys_attributes);
>>> TD_SYSINFO_MAP_MOD_INFO(TDX_FEATURES0, tdx_features0);
>>>
>>> return ret;
>>> }
>>>
>>> With the build time check above, I think it's OK to lose the type-safe
>>> inside the stbuf_read_sysmd_field(), and the code is simpler IMHO.
>>>
>>> Any comments?
>>
>> 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)))
>>
>>
>
> Thanks for the comment, but I don't think this meets for our purpose.
>
> We want a build time "error" when the "MD_FIELD_ELE_SIZE(_field_id) == _size"
> fails, but not "still initializing the size to 0".
FWIW, it isn't 0, it is void. Assignment to void is an error. Could use
anything that is correct syntax but would produce a compile-time error
e.g. (1 / 0).
> Otherwise, we might get
> some unexpected issue (due to size is 0) at runtime, which is worse IMHO than
> a runtime check as done in the current upstream code.
>
> I have been trying to add a BUILD_BUG_ON() to the field_mapping structure
> initializer, but I haven't found a reliable way to do so.
>
> For now I have completed the new version based on Dan's suggestion, but still
> need to work on changelog/coverletter etc, so I think I can send the new
> version out and see whether people like it. We can revert back if that's not
> what people want.
next prev parent reply other threads:[~2024-08-27 4:55 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-17 3:40 [PATCH v2 00/10] TDX host: metadata reading tweaks, bug fix and info dump Kai Huang
2024-07-17 3:40 ` [PATCH v2 01/10] x86/virt/tdx: Rename _offset to _member for TD_SYSINFO_MAP() macro Kai Huang
2024-08-05 22:37 ` Dan Williams
2024-07-17 3:40 ` [PATCH v2 02/10] x86/virt/tdx: Unbind global metadata read with 'struct tdx_tdmr_sysinfo' Kai Huang
2024-08-05 23:32 ` Dan Williams
2024-08-06 0:09 ` Huang, Kai
2024-08-06 1:13 ` Dan Williams
2024-08-07 12:09 ` Huang, Kai
2024-08-26 15:38 ` Adrian Hunter
2024-08-26 22:40 ` Huang, Kai
2024-08-27 4:54 ` Adrian Hunter [this message]
2024-08-27 7:22 ` Huang, Kai
2024-07-17 3:40 ` [PATCH v2 03/10] x86/virt/tdx: Support global metadata read for all element sizes Kai Huang
2024-08-05 23:45 ` Dan Williams
2024-07-17 3:40 ` [PATCH v2 04/10] x86/virt/tdx: Abstract reading multiple global metadata fields as a helper Kai Huang
2024-07-17 3:40 ` [PATCH v2 05/10] x86/virt/tdx: Move field mapping table of getting TDMR info to function local Kai Huang
2024-08-05 23:48 ` Dan Williams
2024-07-17 3:40 ` [PATCH v2 06/10] x86/virt/tdx: Refine a comment to reflect the latest TDX spec Kai Huang
2024-08-06 3:43 ` Dan Williams
2024-08-06 11:23 ` Huang, Kai
2024-08-06 19:06 ` Dan Williams
2024-08-06 21:01 ` Huang, Kai
2024-07-17 3:40 ` [PATCH v2 07/10] x86/virt/tdx: Start to track all global metadata in one structure Kai Huang
2024-08-06 3:51 ` Dan Williams
2024-08-06 11:29 ` Huang, Kai
2024-07-17 3:40 ` [PATCH v2 08/10] x86/virt/tdx: Print TDX module basic information Kai Huang
2024-08-06 4:19 ` Dan Williams
2024-08-06 11:51 ` Huang, Kai
2024-08-06 12:48 ` Huang, Kai
2024-08-07 21:56 ` Dan Williams
2024-08-07 22:32 ` Huang, Kai
2024-08-08 10:31 ` Chenyi Qiang
2024-08-08 23:52 ` Huang, Kai
2024-07-17 3:40 ` [PATCH v2 09/10] x86/virt/tdx: Reduce TDMR's reserved areas by using CMRs to find memory holes Kai Huang
2024-08-06 4:47 ` Dan Williams
2024-08-06 12:17 ` Huang, Kai
2024-08-20 18:38 ` Adrian Hunter
2024-08-27 7:24 ` Huang, Kai
2024-07-17 3:40 ` [PATCH v2 10/10] x86/virt/tdx: Don't initialize module that doesn't support NO_RBP_MOD feature Kai Huang
2024-08-06 4:55 ` Dan Williams
2024-08-06 12:18 ` Huang, Kai
2024-08-05 12:03 ` [PATCH v2 00/10] TDX host: metadata reading tweaks, bug fix and info dump Huang, Kai
2024-08-05 22:36 ` Dan Williams
2024-08-08 0:19 ` 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=7ae1fcac-cbea-478c-b8c9-d2c2a5dd6f11@intel.com \
--to=adrian.hunter@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--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