On Wed, 2024-12-04 at 01:24 +0000, Huang, Kai wrote:
> Currently the global metadata reading script generates the struct member based
> on the "field name" of the JSON file. The JSON file stores them as "size":
>
> "TDR_BASE_SIZE", "TDCS_BASE_SIZE", "TDVPS_BASE_SIZE"
>
> We will need to tweak the script to map "metadata field name" to "kernel
> structure member name", and more "special handling for specific fields" when
> auto generating the code.
>
> It's feasible but I am not sure whether it's worth to do, since we are basically
> talking about converting size to page count.
Ah, right. So given that this is generated code, we should probably just add the
wrappers like you suggest. In any case, we should remove the counts from the new
arch/x86 structs.
>
> Also, from global metadata's point of view, perhaps it is also good to just
> provide a metadata which is consistent with what module reports. How kernel
> uses the metadata is another layer on top of it.
I'm not sure I buy this one though. The exported arch/x86 interface shouldn't
have to match the HW directly.
>
> Btw, perhaps we don't need to keep 'tdcs_nr_pages' and 'tdcx_nr_pages' in
> 'struct tdx_td', i.e., as per-TD variables. They are constants for all TDX
> guests.
>
> E.g., assuming KVM is still going to use them, it can just access them using the
> metadata structure:
>
> static inline int tdx_tdcs_nr_pages(void)
> {
> return tdx_sysinfo->td_ctrl.tdcx_base_size >> PAGE_SHIFT;
> }
>
> AFAICT they are only used when creating/destroying TD for a couple of times, so
> I assume doing ">> PAGE_SHIFT" a couple of times won't really matter.
None of the users are in fast paths. Using page count directly would be more
about reducing wrapper clutter.
