[PATCH v15 16/28] x86/txt: Intel Trusted eXecution Technology (TXT) definitions
ross.philipson at oracle.com
ross.philipson at oracle.com
Thu Dec 18 10:17:11 PST 2025
On 12/18/25 8:34 AM, Dave Hansen wrote:
> On 12/15/25 15:33, Ross Philipson wrote:
>> +static inline void *txt_sinit_mle_data_start(void *heap)
>> +{
>> + return heap + txt_bios_data_size(heap) +
>> + txt_os_mle_data_size(heap) +
>> + txt_os_sinit_data_size(heap) + sizeof(u64);
>> +}
>
> So each one of these walks through the entire table?
>
> Maybe I'm naive, but wouldn't this all be a lot more sane if it was just
> parsed *once* into a table of pointers?
>
> enum {
> FIELD1,
> FIELD2,
> FIELD3,
> MAX_NR
> };
>
> void *parseit(u8 *heap)
> {
> void *ptr_array[MAX_NR] = {};
> void *place = heap;
>
> for (int i = 0; i < MAX_NR; i++) {
> // The buffer starts with the length:
> u32 *size_ptr = place;
>
> // Consume the length:
> place += sizeof(*size_ptr);
>
> // Point at the data:
> ptr_array[i] = place;
> // Consume the data:
> place += *size_ptr;
> }
> // along with some sanity checks
> }
>
> Then, to access FIELDs you do:
>
> struct field1_struct *f1s = ptr_array[FIELD1];
> struct field2_struct *f1s = ptr_array[FIELD2];
>
> Yeah, it means keeping that pointer array around. But <shrug>. It's also
> not about performance. That ^ is a billion times easier to understand
> because it lays out the "heap" logic in one place. You don't have to
> recurse through half a dozen helpers to figure things out.
That is an excellent idea, we will do that. I may be able to use the
same the index scheme when I do the early remap operations too. That
walks the heap each time but does not have to. It just wants a pointer
to what to map.
Thank you,
Ross
More information about the kexec
mailing list