On 3/15/2024 1:39 PM, Huang, Kai wrote:
On Fri, 2024-03-15 at 13:11 +0800, Li, Xiaoyao wrote:
Here is what Isaku can do using the current API:
u64 num_cpuid_config;
>
...
tdx_sys_metadata_field_read(NUM_CPUID_CONFIG, &num_cpuid_config);
tdx_info = kzalloc(calculate_tdx_info_size(num_cpuid_config), ...);
tdx_info->num_cpuid_config = num_cpuid_config;
Dosen't num_cpuid_config serve as temporary variable in some sense?
You need it, regardless whether it is u64 or u16.
For this case, it needs to be used for calculating the size of tdx_info.
So we have to have it. But it's not the common case.
E.g., if we have another non-u64 field (e.g., field_x) in tdx_info, we
cannot to read it via
tdx_sys_metadata_field_read(FIELD_X_ID, &tdx_info->field_x);
we have to use a temporary u64 variable.
Let me repeat below in my _previous_ reply:
"
One example that the current tdx_sys_metadata_field_read() doesn't quite fit is
you have something like this:
struct {
u16 whatever;
...
} st;
tdx_sys_metadata_field_read(FIELD_ID_WHATEVER, &st.whatever);
But for this use case you are not supposed to use tdx_sys_metadata_field_read(),
but use tdx_sys_metadata_read() which has a mapping provided anyway.
"
tdx_sys_metadata_read() is too complicated for just reading one field.
Caller needs to prepare a one-item size array of "struct
tdx_metadata_field_mapping" and pass the correct offset.
So sorry I am not seeing a real example from you.
