[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